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.

[0] https://chiselapp.com/user/rkeene/repository/hunter2/ [1] https://github.com/rkeene/hunter2 (mirror)

Love the name. That alone is genius, never mind all the work you've put into the tool itself.

i'd love to see the genius. what makes it so clever?

Mentioned farther in the thread, but it's based on this: http://bash.org/?244321

How do you know my password?

Just in case anyone doesn’t know the reference:

http://bash.org/?244321

I don't, I just copy and pasted the stars. you see "hunter2" but I see "****"

thats neat, I didnt know HN did that

I found it on a sticky note beneath your mouse pad ;-)

Haha, nice. I’m a happy Password Store user of some 2-3 years, but I starred your repository - very cool idea to use PKCS#11 modules.

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.

>like the need to "ultimately trust" keys before they become usable

Did you have to do that manually at one time? All the keypairs that I make start out that way when created.

When creating a keypair for pass all you have to do is generate the key using defaults while remembering a bit of the user ID to give to pass.

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.

I had to do it when importing keys on another device

Yep the integration with Yubikey is amazing. Both on mobile and desktop <3

SSH has included file encryption for a few versions now, and iirc supports yubikeys — probably would be more useful a backend than age.

> SSH has included file encryption for a few versions now

Mmm. I don't think so. Recent OpenSSH includes file signatures not encryption.

Ahh, you are correct, I misremembered.

Besides that, pass leaks metadata.

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.

There's also the pass-tomb extension [0] which stores the directory in a tomb [1].

[0] https://github.com/roddhjav/pass-tomb

[1] https://www.dyne.org/software/tomb/

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.

https://github.com/ayushnix/pass-coffin

A few pass-related projects are working on an age[1] backend in addition to gpg. I think gopass already has support for it.

[1]: https://age-encryption.org/

Here's one I have been playing with success.

https://github.com/chrisswanda/passage

Correct. Gopass has very early age support. It fully works but the UX is not great (yet).

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?

[0]: https://github.com/android-password-store/Android-Password-S...

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.

[1]: https://github.com/android-password-store/Android-Password-S...

Oh, that's an awesome news. Thank you!

> missing AGE encryption

I am just curious. What makes AGE backend better than GPG one?

As yepguy mentioned AGE is simpler. I can also mention few things:

- It works smoothly with SSH keys (generated from ssh-keygen), which are perfectly recognized by possibly any developer.

- No need for external client, such as GpgWin/Kleopatra for Windows.

- Embed-able in Rust[0] and Go[1] (there are libraries), no need to call `gpg --decrypt ...` from the command line.

- Encrypted files by pass and keys are smaller. I guess it is thanks to ecliptic-curve encryption.

[0]: https://github.com/str4d/rage

[1]: https://github.com/FiloSottile/age

Age is much simpler to use in nearly every way, whether that's interactively (keys are just files!), in scripting, or in implementation.

I'm still sticking to gpg for the foreseeable future, but between age and sequoia[1] I'm hopeful that things will soon be much easier to use.

[1]: https://sequoia-pgp.org/

I get what you’re saying but it’s just different philosophies no?

Seems like pass wants to use the Unix philosophy of “do one thing well” so it relies on gpg for encryption instead of rolling its own.

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.

I just looked into signify, and I read this:

https://www.openbsd.org/papers/bsdcan-signify.html

> 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.