Is a PGP-based password manager a good idea in 2019?

[Allan Odgaard]

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

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...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20190901/67bde35a/attachment.html>