Hello, all:I'm evaluating pass for use within a team of systems administrators, and it seems like a good fit -- thanks again, Jason. :)
I'm curious about the "different keys per subpath" feature, though -- it seems that it would be easy to defeat unless the git repository itself applies some kind of permission control over paths. Say, we have two teams:
Sysadmins: - Alice - Bob Developers: - Cathy - Dwayne The pass hierarchy would be: sysadmins/ .gpg-id = alice, bob systems/ somepass developers/ .gpg-id = cathy, dwayne services/ somepass shared/ .gpg-id = alice, bob, cathy, dwayne services/ somepassWhat's preventing Cathy from inserting her key into sysadmins/.gpg-id? She won't get access to the secrets right away, but the next time a password is added or changed by a sysadmin, it will be encrypted to her key as well as to those of alice and bob.
I know there will be a git log of that change, but it's easy to hide it as part of a larger operation that touches a lot of files (say, Eve joins the development team and both developers/ and shared/ trees get modified to recrypt her key -- so a change to sysadmins/.gpg-id goes unnoticed). Also, if .gpg-id files list keygrips instead of email addresses, spotting a rogue entry will be very difficult in large teams.
Apologies if this has already been discussed -- I've only gone back a few months in the archives.
Best, Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation Montréal, Québec
signature.asc
Description: PGP signature
_______________________________________________ Password-Store mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/password-store
