Protect .gpg-id

Brian Candler b.candler at pobox.com
Wed Dec 7 17:39:20 CET 2016


On 07/12/2016 16:04, Frank Grüllich wrote:
> But now to serious business.  TL;DR: what prevents an attacker to
> manually mess around with .gpg-id files to make people encrypt secrets
> for private keys they own?

Not much.

However there is a variation of this problem which has bitten me 
recently: a person in the team overwrites .gpg-id with just their own 
key, then re-encrypts everything and commits back (*).  The passwords 
are then readable by them but not anyone else :-(

This is rather too easy to break.  The solution is either to rewind the 
repo, or to get the person who caused the problem to re-run 'pass init' 
with the correct set of keys and commit again.

I suspect the simplest way to prevent this is to have a server-side 
update hook which blocks all commits that update .gpg-id files. This 
restriction can be temporarily removed whenever it's necessary to change 
these files - or restricted to commits just from a trusted administrator.

Regards,

Brian.

(*) I think what happened was that he was missing the necessary public 
keys for the other members of the team, and so did 'pass init <hiskey>' 
as a way to "fix" the problem.

It would also be helpful if `pass init` were to warn loudly if there is 
an existing .gpg-id file, which contains any keys that are not in the 
list of keys provided on the pass init command line.



More information about the Password-Store mailing list