[pass] Using pass in a team

Niklas Hambüchen mail at nh2.me
Mon Apr 11 18:36:42 CEST 2016


I have made good experiences with

  PASSWORD_STORE_GPG_OPTS=--trust-model=always

so far. This relies that you trust the (git) repository that contains
your pass folder and specifically the .gpg-id file.

If you put your pass folder on Github for example, then in theory the
Github guys (or anybody who compromises into Github) could add their key
to .gpg-id and then you'll encrypt for them too if you use
`--trust-model=always`. If you assume that the repo is safe, then
`--trust-model=always` is a good and convenient option, and it would
scale to large teams.
If only a few select people need to write new passwords while the others
need to only read, you can also improve security in the presence of
`--trust-model=always` by enabling git's commit signing feature. E.g. in
`pass git log --show-signature` you'll see which commits are signed, if
any. You can then make git fail loudly if some commit is pulled that
isn't signed by one of those people. This is a middle ground solution,
where you only have to trust/sign the keys of those people that can
write passwords, not everybody in .gpg-id (which may be hundreds if you
have a big team).

Depending on what your use case is, using multiple pass repos (e.g. one
per team) may be an alternative to giving different .gpg-ids per folder.

On 11/04/16 16:12, David Adam wrote:
> Phil,
> 
> I wrote a wrapper script to handle all our key management and 
> re-encryption, which I imagine most teams have also done. I can send you a 
> link if you're interested, although it doesn't do revocation (needs to be 
> done by hand).
> 
> In particular, we set the GPG trust model to "always". Having thought 
> about it, if you can modify our keyring then you can modify our version of 
> GPG to backdoor it, so there's not much point in trying to verify each 
> others' keys. Other teams may have a different situation.
> 
> David Adam
> zanchey at ucc.gu.uwa.edu.au
> 
> On Fri, 8 Apr 2016, Emil Lundberg wrote:
>> As for your first question, the two are orthogonal. Multiple keys can be
>> used for the store, allowing multiple users to read (and write to) it; and
>> different key sets can be used for different folders in the store.
>>
>> Second: yes, it's possible to reencrypt the store with a new key (or keys)
>> as long as you can still decrypt it (i.e. you still have the previous
>> private key). Do keep in mind, however, that any copies of the store
>> (including snapshots in git history, if the git feature is used) are not
>> affected and can still be decrypted with the old key.
>>
>> /Emil
>>
>> On Fri, 8 Apr 2016, 15:44 Philip Colmer, <philip.colmer at linaro.org> wrote:
>>
>>> The home page says:
>>>
>>> Multiple GPG keys can be specified, for using pass in a team setting
>>>
>>> Is that intended to be read in connection with the bit that follows,
>>> namely "different folders can have different GPG keys", or does it
>>> mean that each team member can use their own personal key yet still
>>> access the store? I'm having trouble figuring out how the latter would
>>> work, if it is possible :).
>>>
>>> Also, is it possible to change the key used by the store? I couldn't
>>> see that in the documentation. I'm thinking of a scenario where the
>>> store's key might become compromised, i.e. leak in the wild, through
>>> carelessness or similar, leaving us needing to re-protect the store.
>>>
>>> Thanks.
>>>
>>> Regards
>>>
>>> Philip
> _______________________________________________
> Password-Store mailing list
> Password-Store at lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/password-store
> 


More information about the Password-Store mailing list