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