8 ms·

`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 en

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

jamal-kumar 5y ago
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.
- yepguy 5y ago
  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/ https://age-encryption.org/
  - zikduruqe 5y ago
    Here's one I have been playing with success. https://github.com/chrisswanda/passage https://github.com/chrisswanda/passage
  - tex0 5y ago
    Correct. Gopass has very early age support. It fully works but the UX is not great (yet).
    - pqb 5y ago
      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-Store https://github.com/android-password-store/Android-Password-S...
      - yepguy 5y ago
        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-Store/issues/1195#issuecomment-808940598 https://github.com/android-password-store/Android-Password-S...
        pqb 5y ago
        Oh, that's an awesome news. Thank you!
      - cobby 5y ago
        > missing AGE encryption I am just curious. What makes AGE backend better than GPG one?
        yepguy 5y ago
        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/ https://sequoia-pgp.org/
        pqb 5y ago
        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 https://github.com/str4d/rage [1]: https://github.com/FiloSottile/age https://github.com/FiloSottile/age
- HotHotLava 5y ago
  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.
  - beagle3 5y ago
    SSH has included file encryption for a few versions now, and iirc supports yubikeys — probably would be more useful a backend than age.
    - tialaramex 5y ago
      > SSH has included file encryption for a few versions now Mmm. I don't think so. Recent OpenSSH includes file signatures not encryption.
      - beagle3 5y ago
        Ahh, you are correct, I misremembered.
  - _abox 5y ago
    Yep the integration with Yubikey is amazing. Both on mobile and desktop <3
  - yepguy 5y ago
    https://github.com/str4d/age-plugin-yubikey https://github.com/str4d/age-plugin-yubikey
  - upofadown 5y ago
    >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.
- rank0 5y ago
  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.
- vngzs 5y ago
  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.
  - karlding 5y ago
    There's also the pass-tomb extension [0] which stores the directory in a tomb [1]. [0] https://github.com/roddhjav/pass-tomb https://github.com/roddhjav/pass-tomb [1] https://www.dyne.org/software/tomb/ https://www.dyne.org/software/tomb/
  - ayushnix 5y ago
    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 https://github.com/ayushnix/pass-coffin
- ayushnix 5y ago
  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.
rkeene2 5y ago
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/ https://chiselapp.com/user/rkeene/repository/hunter2/ [1] https://github.com/rkeene/hunter2 https://github.com/rkeene/hunter2 (mirror)
- hnlmorg 5y ago
  Love the name. That alone is genius, never mind all the work you've put into the tool itself.
  - waynesonfire 5y ago
    i'd love to see the genius. what makes it so clever?
    - deleted 5y ago
      [deleted]
    - rrauenza 5y ago
      Mentioned farther in the thread, but it's based on this: http://bash.org/?244321 http://bash.org/?244321
- SpaceManNabs 5y ago
  How do you know my password?
  - Overtonwindow 5y ago
    I found it on a sticky note beneath your mouse pad ;-)
  - laumars 5y ago
    Just in case anyone doesn’t know the reference: http://bash.org/?244321 http://bash.org/?244321
rectang 5y ago
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.
- tialaramex 5y ago
  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.
  - rectang 5y ago
    I just looked into signify, and I read this: https://www.openbsd.org/papers/bsdcan-signify.html 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.
plafl 5y ago
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.
deleted 5y ago
[deleted]

jamal-kumar 5y ago

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.

yepguy 5y ago
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/ https://age-encryption.org/
- zikduruqe 5y ago
  Here's one I have been playing with success. https://github.com/chrisswanda/passage https://github.com/chrisswanda/passage
- tex0 5y ago
  Correct. Gopass has very early age support. It fully works but the UX is not great (yet).
  - pqb 5y ago
    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-Store https://github.com/android-password-store/Android-Password-S...
    - yepguy 5y ago
      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-Store/issues/1195#issuecomment-808940598 https://github.com/android-password-store/Android-Password-S...
      - pqb 5y ago
        Oh, that's an awesome news. Thank you!
    - cobby 5y ago
      > missing AGE encryption I am just curious. What makes AGE backend better than GPG one?
      - yepguy 5y ago
        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/ https://sequoia-pgp.org/
      - pqb 5y ago
        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 https://github.com/str4d/rage [1]: https://github.com/FiloSottile/age https://github.com/FiloSottile/age
HotHotLava 5y ago
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.
- beagle3 5y ago
  SSH has included file encryption for a few versions now, and iirc supports yubikeys — probably would be more useful a backend than age.
  - tialaramex 5y ago
    > SSH has included file encryption for a few versions now Mmm. I don't think so. Recent OpenSSH includes file signatures not encryption.
    - beagle3 5y ago
      Ahh, you are correct, I misremembered.
- _abox 5y ago
  Yep the integration with Yubikey is amazing. Both on mobile and desktop <3
- yepguy 5y ago
  https://github.com/str4d/age-plugin-yubikey https://github.com/str4d/age-plugin-yubikey
- upofadown 5y ago
  >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.
rank0 5y ago
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.
vngzs 5y ago
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.
- karlding 5y ago
  There's also the pass-tomb extension [0] which stores the directory in a tomb [1]. [0] https://github.com/roddhjav/pass-tomb https://github.com/roddhjav/pass-tomb [1] https://www.dyne.org/software/tomb/ https://www.dyne.org/software/tomb/
- ayushnix 5y ago
  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 https://github.com/ayushnix/pass-coffin
ayushnix 5y ago
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.

rkeene2 5y ago

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/ https://chiselapp.com/user/rkeene/repository/hunter2/ [1] https://github.com/rkeene/hunter2 https://github.com/rkeene/hunter2 (mirror)

hnlmorg 5y ago
Love the name. That alone is genius, never mind all the work you've put into the tool itself.
- waynesonfire 5y ago
  i'd love to see the genius. what makes it so clever?
  - deleted 5y ago
    [deleted]
  - rrauenza 5y ago
    Mentioned farther in the thread, but it's based on this: http://bash.org/?244321 http://bash.org/?244321
SpaceManNabs 5y ago
How do you know my password?
- Overtonwindow 5y ago
  I found it on a sticky note beneath your mouse pad ;-)
- laumars 5y ago
  Just in case anyone doesn’t know the reference: http://bash.org/?244321 http://bash.org/?244321

rectang 5y ago

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.

tialaramex 5y ago
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.
- rectang 5y ago
  I just looked into signify, and I read this: https://www.openbsd.org/papers/bsdcan-signify.html 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.

plafl 5y ago

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.

deleted 5y ago

[deleted]