Password Safe: a single-file password manager that has outlasted its platform

One encrypted file and one master password

The introduction describes the category first, and then says what makes this one different. Like many other such products, commercial and otherwise, it stores your passwords in an encrypted file, allowing you to remember only one password, the master password, instead of all the username and password combinations you use.

The differentiators are listed as three things. Simplicity, in the sense that Password Safe is designed to do one thing and to do it well: start the application, enter the master password, double-click the entry and the password is on your clipboard, ready for pasting. Security, with the note that the original version was designed by Bruce Schneier, linked to his academic page on the original Password Safe. And open source, with the source available for inspection.

That workflow description is the design in miniature, and it is worth reading carefully because it explains the whole architecture. There is no search-then-copy workflow, there is no browser integration, there is no account. There is a tree of entries, a double-click, and a clipboard. A password manager that does one thing well is a different proposition from one that does many things, and the documentation does not pretend otherwise.

The platform story is in the same paragraph, and it is a striking one. The current version runs on Windows 10 and later, and older versions are still available supporting Windows 95, 98, ME, NT, 2000, XP, Vista and 7. The Mac version runs on macOS 10.14 Mojave and later, and runs native on Intel and Apple Silicon as a universal binary. Linux packages are available for popular distributions, and FreeBSD is also supported.

So the current build matrix is four modern platforms plus a Linux distribution package set, and behind it sits a line of releases that ran on Windows 95. That is the clearest possible statement of what longevity in a project like this looks like.

The build system is the archive of a twenty year project

The repository listing is the most interesting document in the project, because it shows what has accumulated rather than what was designed.

There are Makefiles for six operating systems: Makefile.linux, Makefile.macos, Makefile.windows, Makefile.freebsd, Makefile.openbsd and a generic Makefile at the top. There are two Visual Studio solutions, pwsafe-15.sln and pwsafe-16.sln, plus a wxWidgets solution pwsafe_wx-15.sln, which corresponds to the fact that the non-Windows builds use wxWidgets. There are CMakeLists.txt, CMakePresets.json and a CMakeModules directory for the modern build, CodeBlocks and CodeLite directories for the older IDE projects, and an Xcode directory for the Mac build.

The top level Makefile is a dispatcher, and it is only eleven lines of logic. It detects the operating system from uname -s, includes the corresponding platform Makefile for Linux, CYGWIN, Darwin, FreeBSD or OpenBSD, and errors out with "Unsupported OS or unable to determine OS" for anything else. It also holds the GPG key identifier used for signing, and the SourceForge upload path for the release process.

The source tree splits into src/ for the implementation, with version.mfc and version.wx holding the version strings for the two flavours of the application, xml/ for what is presumably the data format, help/ for the help files, install/ for the installer, docs/ for the documentation, and Misc/ for odds and ends.

Two of the root files stand out. LICENSE is the Artistic License 2.0, and pugixml.LICENSE sits beside it because Password Safe 3.29 and later uses the pugixml project. The presence of a separate licence file for a dependency in the repository root is a small sign of a project that has been careful about attribution for a long time.

The CI configuration tells the same story from the other side. There are separate workflows for the codeql analysis, for macOS, and for the CMake builds, plus a Gitpod configuration with a .gitpod.Dockerfile and a .gitpod.yml so that a contributor can have a working build environment in one click, and a Gitpod Ready-to-Code badge pointing at the repository.

The licence is a stack, and the stack has a commercial clause in it

The licensing situation needs stating carefully, because it is the one place where this project differs from the usual expectation for a security tool.

The project itself is available under the standard Artistic License 2.0, with the details in the LICENSE file that comes with the package. The Artistic License is a permissive licence, but unlike MIT it carries a condition about modified versions being distributed as modified rather than under the same name, and it has a patent grant with a termination clause, which is generally friendlier to a commercial adopter than GPL but not identical to MIT.

Then there are the two dependencies, and they are licensed differently from the application.

From version 3.29 onward, Password Safe makes use of the pugixml project, which is available under the MIT licence. The non-Windows versions of Password Safe make use of wxWidgets, under the terms defined in the wxWidgets licence page, which is described as basically LGPL with an exception stating that derived works in binary form may be distributed on the user's own terms.

That exception is the part that matters to anyone thinking about shipping a modified build. An LGPL dependency normally obliges you to offer the corresponding source of the library. The wxWidgets exception removes that obligation for binary distribution, which is why a closed source commercial product can be built on the wxWidgets version of Password Safe. The Windows build, which does not use wxWidgets, has a different dependency profile again.

The project record lists the licence as a custom one that GitHub cannot classify, which is consistent with the Artistic License 2.0 being a choice GitHub's licence detector does not offer as a standard option. For a security tool, the interesting point is that the code is readable by anyone, and the licence is the permissive end of the scale, with a patent grant in the Artistic terms. A commercial product embedding a modified Windows build has to check the Artistic conditions on its own modifications, and the LGPL exception applies to the wxWidgets builds, which is a distinction most readers will not think about until it matters.

Nineteen languages, and a translation workflow rather than a pull request

The internationalization section lists nineteen languages, and the list itself is a good description of who uses the project.

Arabic, Czech, Chinese, Danish, Dutch, French, German, Hungarian, Italian, Korean, Polish, Portuguese (Brazilian), Russian, Slovak, Slovenian, Spanish, Swedish and Turkish. That is a spread from East Asia to Central Europe to South America, and it says something about a tool that people keep for twenty years and then translate into the language they think in.

The workflow, though, is not the pull request model most open source projects use. You can update the translations or add another language via transifex, or by dropping the maintainer a note through the contact form on pwsafe.org. So the translator path runs through a hosted translation platform and a direct line to the maintainer, rather than through the GitHub issue tracker where the code contributions go.

That division is consistent with the rest of the project. Code contributions go to the developer's mailing list at lists.sourceforge.net or through the web form, bugs are reported through the SourceForge bug tracking form or the GitHub issues, and feature requests have their own SourceForge page. New releases are announced on a separate passwordsafe-announce mailing list.

For a user of the project this matters only in one way, which is that the maintenance model is visible and slow rather than fast and distributed. A code change goes to a mailing list and is reviewed by whoever maintains the project, a translation goes through Transifex, and a release is announced to a list. That is a coherent arrangement for a project with a stable user base that has been around since the 1990s, and it is a very different shape from a project with a large contributor graph.

The Windows build and the wxWidgets build are two different applications

The source tree makes clear that Password Safe is not one program but two related ones, and the split is visible in the file names.

There is version.mfc and version.wx, which are the version resources for the two flavours. There is pwsafe-15.sln and pwsafe-16.sln for the Windows builds, and pwsafe_wx-15.sln for the wxWidgets build used on the non-Windows platforms. There are separate release notes, ReleaseNotes.md for the Windows version and ReleaseNotesWX.md for the Linux and Mac versions, and separate platform Makefiles.

The MFC in the Windows version name is the Microsoft Foundation Classes, which is a fairly old decision for a Windows desktop application, and it explains why the Windows build needs its own solution file rather than sharing one with the wxWidgets code. Two applications means two sets of bugs, two sets of release notes, and a user on Windows who reads the wxWidgets release notes is reading the wrong document.

The topic list on the project record names the platforms as linux-app and windows, which is a useful correction to the assumption that this is a cross-platform project in the usual sense. The macOS, Linux, FreeBSD and OpenBSD builds all come from the same wxWidgets source, and the Windows build is a separate application built with a different toolkit.

There is also a flatpak readme file, README.LINUX.FLATPAK.md, alongside README.LINUX.md, so Linux packaging is handled at least in two ways, and the CMake build with CMakePresets.json appears to be the newer path that the non-Windows platforms are moving towards.

Where a desktop password manager is the wrong shape

Three situations rule it out.

The first is a team that needs sharing. Password Safe's model is one encrypted file protected by one master password, held by one person or one machine. There is no account, no server and no role model, which is exactly what makes it simple and exactly what makes it wrong for a team with shared credentials. The documentation does not describe a sharing or sync feature, and a file that one person edits while another reads is a conflict waiting to happen.

The second is a browser-first workflow. The description of the interaction is double-click, copy, paste, and that is a desktop application flow. A password manager that lives in the browser and fills fields needs a browser extension and a native messaging host, and the project does not describe either. If your day is spent in a browser with forty accounts, this is a different category of tool from what the project is.

The third is a recovery story with more than one key. Everything rests on the master password, which is a real property for a security tool, since there is nothing to phish and no account to take over. It is also a single point of failure, and the documentation does not describe a recovery path beyond the master password.

There is also the honest question of what a file format twenty years old means for a security product, particularly one whose archive includes a version that ran on Windows 95. Format stability is valuable, because your old file still opens. It also means the format itself is fixed, and the security properties of what is stored inside it are those of decisions made a long time ago.

The remaining question is whether the narrowness is a feature or a limit, and the documentation is clear that it is intended as a feature. The project states that it is and will always remain an open source project, free for use and redistribution, while asking for donations to justify the time spent maintaining it. That combination, a long-lived file format, a deliberate single feature and an open licence, is coherent.

Editorial conclusion

Password Safe fits a person who wants one encrypted file they can open anywhere, on any platform, without an account or a subscription, and who is comfortable with a desktop application rather than a browser extension or a hosted service. It is the wrong choice for a team that needs sharing, roles or a recovery path beyond the master password, and it is the wrong choice if you need the features modern password managers compete on, such as autofill across browsers, passkeys or hardware key support. Before adopting it, confirm the platform you care about is in the current build matrix rather than the legacy one, read the release notes for the version you pick, and settle the licensing question early, because the Artistic License 2.0 and the MIT-licensed and wxWidgets-licensed components underneath it are not the same terms as a permissive open source licence for a redistributed product.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. pwsafe/pwsafe on GitHub
4. README
5. Releases