QtPass: a cross platform GUI that drives the pass password store

A front end, not a new password store

QtPass is a multi-platform GUI for pass, the standard Unix password manager, providing a secure and intuitive way to manage your passwords, and the first feature in the list is the one that defines the whole design: using `pass` or `git` and `gpg2` directly. Nothing is reimplemented and nothing is moved. Your existing `~/.password-store` remains the source of truth, your GnuPG keys remain the encryption, and git remains the sync mechanism if you use it. The README makes this explicit for the AppImage build, which bundles Qt only and uses the `pass`, `gpg2`, `git` and `gpg-agent` already installed on your system, so your existing store, your pinentry and your smartcard all keep working, with no sandbox permissions to grant. The security story is therefore inherited rather than asserted. If you are worried about a password manager's own encryption and handling, that is a question about GnuPG and pass, and QtPass sits on top of them. What the project adds is the desktop experience that a command line password store has never had, in over 60 languages.

The features that a terminal password store cannot offer

Reading the feature list is a good way to see which annoyances the project is aimed at. Password generation comes with configurable complexity, and content search across decrypted entries works with regular expressions, and it is opt-in, which is the right default for a feature that decrypts every entry in the store to search it. TOTP support is built in, with no external extension needed, which removes the usual step of pairing a second application with a secret. There is per-folder user selection for multi-recipient encryption, and a share submenu that re-encrypts a folder, exports your public key and adds recipients, so sharing a single credential with a colleague does not mean sharing the whole store. Security conscious details are present too: configurable shoulder surfing protection, smartcard and USB token support over OpenPGP including YubiKey, and the ability to import GPG keys from a file or the clipboard without leaving the application. The process output panel, with command labels, color coded errors and auto-scroll, is a small feature that changes the experience, because a password manager that runs external commands should show what it ran. The README also notes that profiles and templates, OTP and Git sync are explained in more detail on the advanced page of the project site.

Profiles group passwords by repository and by key

Profiles are the feature that turns QtPass from a viewer into something you can organise with. Each profile might use a different Git repository and/or a different GPG key, and each profile can also be associated with a GPG key to sign and verify the `.gpg-id` file for integrity. The typical use case, as the README puts it, is to separate personal and work passwords. There is also a hint that changes the shape of the setup: instead of using different Git repositories for the various profiles, you could synchronize with different branches from the same repository, by cloning the repository into the profile folders and checking out the related branch. The example in the README sets up two profile folders inside the password store, with the repository URLs as variables so the same script works for anyone:

cd ~/.password-store/
# Replace these with your own repositories (HTTPS or SSH).
PERSONAL_REPO_URL="<your-personal-password-repository-url>"
WORK_REPO_URL="<your-work-password-repository-url>"

Signing the `.gpg-id` file is the part worth pausing on. It means the profile carries a cryptographic statement about which key the folder is meant to be encrypted to, and a key that does not match will be noticed rather than silently accepted, which is a meaningful protection when a profile is shared between two people or restored on a new machine.

Installing it: eight package managers, one unsigned Windows installer

The packaging is broad, and every route the README lists is a single command. OpenSUSE and Fedora use `yum install qtpass` or `dnf install qtpass`, Debian and its derivatives including Mint, Kali and Raspbian use `apt-get install qtpass`, Arch uses `pacman -S qtpass`, Gentoo uses `emerge -atv qtpass`, Sabayon uses `equo install qtpass`, FreeBSD uses `pkg install qtpass` and OpenBSD uses `pkg_add qtpass`. Repology packaging badges confirm the distribution coverage. macOS is the awkward one: you download the `.dmg` from the releases page and clear the quarantine flag with `xattr -d com.apple.quarantine /Applications/QtPass.app`, and the Homebrew cask was disabled in September 2026 because the app is not notarized. Windows is similar in shape: `choco install qtpass` or `winget install IJHack.QtPass`, with an installer that is not code-signed yet, so SmartScreen asks for More info and Run anyway on first start, and signing is being set up under a published code signing policy. The Linux AppImage route downloads `QtPass-<version>-x86_64.AppImage` and runs it, and it has hard requirements worth knowing: glibc 2.39 or newer, meaning Ubuntu 24.04, Debian 13 or Fedora 40 and later, and `libfuse2`, or the `--appimage-extract-and-run` option on systems without it.

Building from source needs Qt 6.8 and a graphical pinentry

The source build is short on Unix systems, where the README says that on most systems all you need is:

qmake6 && make && make install

The requirements behind that one line are where the work is. QtPass requires Qt 6.8 or later and is built with `qmake6`, and Qt 5 support ended with QtPass 1.8, so a distribution still on Qt 5 cannot use the current release. The Linguist package is required to compile the translations, and the SVG library is required for the fallback icons. At runtime `gpg2` with GnuPG 2.2 or newer is required, while `git` is optional and used for repository sync, and `pass` itself is optional since the application can use native GPG and Git directly, which is a useful detail for people who like the store format but not the script. Your GPG must be configured with a graphical pinentry when applicable, and the same goes for Git authentication, and on macOS `pinentry-mac` from Homebrew is said to work best, with gpgtools as an alternative. A Flatpak package is present in the repository as well, for distributions that prefer it.

The project is serious about supply chain hygiene

The badge wall at the top of the README is longer than most desktop application projects manage, and it is a signal about how the project is run. There is an OpenSSF Best Practices badge, an OpenSSF Scorecard badge, a REUSE status badge, a FOSSA status badge, a translation status badge hosted on Weblate, a build and test workflow badge, coverage through both Coveralls and codecov, and a CodeFactor badge. The repository contents match that posture. There is a `LICENSES/` directory with a `REUSE.toml` file, which is the machine readable way to declare per file licensing, a `flatpak/` directory, a `qtpass.spec` file for RPM based distributions, a `qtpass.iss` file for the Windows installer, an AppStream metadata file, a `publiccode.yml` for public sector catalogues, a man page, and a `.signpath/` directory pointing at the signing service whose setup the README mentions for Windows. There is also a CHANGELOG, a ROADMAP, a FAQ, a SECURITY policy, a code of conduct and a CONTRIBUTING guide, and a set of agent instruction files. The translation setup deserves a mention, since it is a large part of the project's reach: the interface is translated into more than sixty languages, maintained through Weblate, with a Transifex configuration in the tree.

The 2.0 line is in release candidate, and the packaging gaps are the real risk

The release history shows the stable and the next line running in parallel: v1.8.3 on 2026-10-06, v2.0.0-rc2 on 2026-10-05 and v2.0.0-rc1 on 2026-09-24, with the last push on 2026-10-18. So the 2.0 line is in release candidate while 1.8.3 remains the version most distributions ship, and the numbering means an upgrade is a decision rather than an automatic bump. The practical limitations are not in the code. They are in the packaging and in the prerequisites. The macOS application is not notarized, which is why the Homebrew cask was disabled, so macOS users have to download a disk image and clear the quarantine flag by hand, and that is friction that will push some users to another client. The Windows installer is not code-signed, so SmartScreen interrupts on first start. Both gaps are acknowledged in the project documentation and are being addressed, but until they are, a cautious deployment has to plan around them. The other constraint is GnuPG itself: a graphical pinentry, a working key, and a store that already exists. QtPass makes that easier to use, not easier to set up.

Editorial conclusion

Adopt QtPass if you already keep your passwords in a pass store with GnuPG and want a desktop interface for it on Linux, macOS or Windows, especially if you need TOTP codes, profiles or smartcard keys in one place. Do not adopt it if you are not willing to configure GnuPG with a graphical pinentry, since that is a hard requirement, and treat the macOS and Windows packaging as a factor in your decision, because the Homebrew cask was disabled in September 2026 for lack of notarization and the Windows installer is still unsigned. Before you install, read the getting started page for GnuPG and pass setup, and decide whether profiles use separate repositories or separate branches, since the README shows both approaches. The licence is GPL-3.0, the stable line is 1.8.3 from 2026-10-06, and 2.0.0 is in release candidate.

Frequently asked questions

Official sources

1. IJHack/QtPass on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases