[pass] There is no assurance this key belongs to the named user

[Roman Valls Guimera]

Thanks everyone, I forgot about the trustdb, I just fixed it. Perhaps a friendlier pass error message could inform the user after gpg error messages?

Something like ”Please check the trust level of the key defined in .gpg-id” could come handy.

Thanks!

16 apr 2014 kl. 13:22 skrev Jason A. Donenfeld <Jason at zx2c4.com>:

> On Wed, Apr 16, 2014 at 4:31 AM, Nathan Typanski <ntypanski at gmail.com> wrote:
>> On 04/16, Jason A. Donenfeld wrote:
>>> [...] adding "--trust-model always" to the relevant $GPG invocation
>>> suppresses that message? [...] mailing list: do we want to add this?
>> 
>> I will argue a resounding NO.
>> 
>> Please note the way pass is deciding whose public key to use. It's
>> just reading from $HOME/.password-store/.gpg-id by default, and
>> iterating over the keys in that file.
>> 
>> Thus we have a potential security issue where that file has incorrect
>> permission bits (unlike e.g. ssh, which will not execute if the
>> permissions are set incorrectly) and is writable by more programs than
>> we might prefer. Even assuming this kind of file permission bit
>> control were in place, it would still be vulnerable to all programs
>> that we launch as ourselves!
>> 
>> If some program gains write access to that file, they can tell me to
>> encrypt my next password generation or edit to their GPG key. Now
>> hopefully this will not be someone I know and have trusted the public
>> key of, since if this is the case then we can protect against it.
>> 
>> How do we guard against such a remote threat? Easy! We just do
>> nothing. GPG will do the right thing and not encrypt our passwords to
>> the attacker's public key, because their key is not in our keyring and
>> we don't trust it anyhow.
>> 
>> If we modify this default behavior to blindly trust the .gpg-id file,
>> then we forfeit any trust-model protection that GPG can offer.
> 
> I'm compelled by this line of reasoning. Thanks for your mail Nathan.