Is a PGP-based password manager a good idea in 2019?
lists+pass at simplit.com
Sun Sep 1 12:24:13 CEST 2019
On 1 Sep 2019, at 11:13, Brian Exelbierd wrote:
> [...] In theory an alternate program, using libsodium or whatever,
> that stored the shareable config (nonce, etc.) in the password repo
> and that used the same pinentry as GPG would go unnoticed by me.
Sure, if we re-implement the features currently being used from GPG,
switching to an alternative would go unnoticed :)
But that feature list also includes key management, for example teams
may encrypt passwords for multiple recipients and/or with different keys
for different sub-folders.
So it is not trivial to re-implement these features, even if we rely on
And I do think that having a repository with .gpg files is better than
custom .pass files, as many things can operate on .gpg files, where
nothing (but a hypothetical `pass` command) can operate on the latter,
and it may not expose low-level commands to do the same operations that
are currently possible to do with gpg.
> How is libsodium, or any other format, proprietary when compared to
> GPG? It seems they just have different formats which mean different
> programs can read them. It seems that just as a GPG encrypted file
> can be read on any machine with GPG installed, a libsodium encrypted
> file has the same properties.
Libsodium is a utility library and does not define any file formats,
therefore using it would mean inventing our own file formats.
You can argue that .gpg files are exclusive to the `gpg` command, and I
do not disagree, but I do think there is a difference, as `pass` is not
a utility to encrypt/decrypt files nor manage public/private keys,
therefore it would be unlikely to expose the same operations as `gpg`
when it comes to operating on its data files, and in that sense, I would
consider the data files proprietary to `pass`.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Password-Store