`pass` was written by Jason Donenfeld, the developer who gave us WireGuard.
It's is a bash script that makes it convenient and easy to use gpg2, the OpenPGP encryption tool. Frankly, I'm kind of shocked at how difficult it is to use the gpg2 command line utility. Clearly it's an extremely powerful tool, but it's written with the assumption that the user has a very deep understanding of how encryption and key signing work. To use `pass` effectively you should have a basic understanding of encryption, but unlike gpg2 you don't need to dedicate a week to grok the manpage.
I wrote a tool called hunter2 [0][1] which is very similar but uses PKCS#11 modules, which may be more common than GPG since the entire US Government uses them.
As much as I love Jason Donenfeld's work, I tried to use pass and the gpg requirement just rubbed me the wrong way. It's basically just gpg-encrpyting a text file and unlocking that along with some wrappers for basic password manager functionality (I guess most important is clipboard functionality and clearing it automatically after some seconds), but somehow that seems like a weak point to me. It's a whole lot of reliance on one extremely bloated suite of applications when I feel like something standalone and about as compact would be better somehow.
As a user, I also often feel like `gpg` brings a lot of annoying accidental complexity to `pass`, (like the need to "ultimately trust" keys before they become usable) but on the other hand it enables integration with hardware tokens like Yubikeys and in extension mobile devices (via openkeychain) that as far as I know wouldn't be possible with a more modern age-based backend.
Yes, every time I want to set it up on a new device I have to import and trust all public keys that it should encode to; and if that device gets its own gpg key then that key also has to be distributed to and trusted at all prior sites. Which isn't very often, but still somewhat regularly (ie. new laptop, new yubikey, formatted hard drive, etc.)
I think it would be a great addition if pass could actually automate this by storing all relevant public keys internally.
Ah, yes that is a nuisance. GPG has the "--export-ownertrust" and "--import-ownertrust" commands to make that sort of thing less tedious.
In general I think you are supposed to only have a one or a few "ultimately trusted" keys and then distribute that trust by signing the rest. So once you change the trust on one key the trust distributes automatically.
If your passwords are the only part of your password manager you think are secret, then you're probably not considering the utility of an enumeration of all your network handles. Mine aren't very interesting, but I wouldn't post that on GitHub, even in a private repo.
I love pass and use it. But when I need to carry my password database around, I don't rely on pass alone - I throw the pass database in a Veracrypt container. That way if my flash drive is stolen, it's just an encrypted blob.
Besides pass-tomb, there's also pass-coffin which doesn't need to rely on a 3k+ line ZSH script. I'll add support for using age and signify in pass-coffin soon.
Oh dammit. I have stopped using Gopass and rewrote pass just for that reason - missing AGE encryption. At least I have learned something new and I feel I have better UI - fuzzy finder instead of their TUI. However, big kudos to Gopass team for awesome work and really useful tool.
Before I start working on next project... Do you recognize any mobile app, which could replace PasswordStore app for Android [0] but with AGE support?
Android Password Store itself is keen to add age support[1], but I don't know of anything usable right now. You could probably use gopass in termux in the mean time.
FWIW, adding support for age in pass is listed as one of the goals of age. I'm considering sending an upstream patch in pass to support age and signify as well.
I don't know why, but I usually find the usability of anything crypto-related terrible like ssh or managing certificates. Granted I have no idea about security but I would say that I have some knowledge of computers, I use 2FA minimum everywhere, I use VPN almost daily, I ssh into machines frequently, I use a password manager, I update my software and I'm picky about what I install. You get the idea. And yet I dread having authentication problems, my only resort googling to see what other poor souls managed to do. I think some part of it is part of the nature of the problem since you have to assume some of your users are malicious but a good part is just not caring, like if you don't know what the problem is you should not even be close to a computer.
I wish someone would mint a user-friendly GPG wrapper for signing releases and quorum-based publishing. Dealing with raw GPG to sign releases is doable but a pain. And we need quorum publishing to guard against supply-chain attacks.
But simple and user-friendly UX design is hard. As a user of `pass`, I'm grateful for what I have.
For the signing problem, both signify (and its clones) and modern OpenSSH (ssh-keygen -Y) do what you want today without all the baggage of OpenPGP, obviously that would mean explicitly choosing to migrate off OpenPGP signatures, but that does not seem unreasonable.
> There are no key servers for signify. No web of trust. Just keys.
I'm not sure how that would work for quorum publishing, which guards against any single set of credentials being compromised by requiring multiple trusted signatories. The idea is that packages are signed by multiple identities, and if as a downstream user, you trust enough of those identities to form a quorum (2, or 3, or some score-based criteria), then you consider the release trustworthy enough to accept automatically. (The underlying theory is just multifactor auth.)
Downstream users need some way of determining how to trust keys, and that mechanism should be decentralized. This seems to be at odds with the priority the BSD authors place on key rotation:
> After each release of OpenBSD, we generate a new key pair for the release after next. That's plus two. For example, after 5.6 was released, keys for 5.8 were generated. This way, the 5.8 keys are then included in the 5.7 release. So, if you upgrade every release, you will have an unbroken chain of keys back to your initial installation.
So it sounds like there's a single set of keys for each release, which has to be kept safe. I'm sure that the OpenBSD folks take great care, but the idea of quorum publishing is to require multiple factors so that an attacker has to compromise multiple identities to spoof a release.
It's is a bash script that makes it convenient and easy to use gpg2, the OpenPGP encryption tool. Frankly, I'm kind of shocked at how difficult it is to use the gpg2 command line utility. Clearly it's an extremely powerful tool, but it's written with the assumption that the user has a very deep understanding of how encryption and key signing work. To use `pass` effectively you should have a basic understanding of encryption, but unlike gpg2 you don't need to dedicate a week to grok the manpage.