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`.
_______________________________________________ Password-Store mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/password-store
