Protect .gpg-id

[Brian Candler]

On 07/12/2016 16:52, Emile Cantin wrote:
> I think the key here is that 'pass init' reads and re-encrypts 
> everything with the new key(s), but Eve didn't actually use 'pass 
> init' but did it manually (because she can't read the files). This 
> leads to a situation where files in the directory are encrypted with a 
> different set of keys than the ones present in .gpg-id, which might be 
> detectable. Perhaps we can try to detect that kind of situation and 
> throw a big nasty warning in these cases?
Interesting idea. Simplest option: whenever re-encrypting an existing 
file (either via 'pass init' or via 'pass edit'), check if the set of 
keys it was previously encrypted to is different to the new set.

*** WARNING: foo/bar ***
THE SET OF KEYS BEING USED TO ENCRYPT THIS FILE IS NOT THE SAME AS BEFORE!
 >>> Encrypting using new key: 0123456789ABCDEF
 >>> No longer encrypting for key: 56789ABCDEF01234
Are you sure you want to continue?

That would be a start, although you have to trust everyone else to be 
vigilant.

I suppose it would still be possible for Eve to:

- update .gpg-id to point to A/B/E
- put in a dummy (e.g. blank) password file, encrypted with A/B/E
- hope that the next time A or B accesses it they think that the empty 
file was a bug, and replaces it with the correct password??