Comment by peanut-walrus

Agreed with 1 and 3, just a tip re 2 though: sops encodes json and yaml semantically, key names of objects are preserved. Iow you can see which key changed.

Whether that is a feature or a metadata leak is up to the beholder :)

git-crypt solves all 3 (mostly)

> Sharing encryption key for all team members

you're enrolling a particular users public/key and encrypting a symmetric key using their public key, not generating a single encryption key which you distribute. You can roll the underlying encryption key at any time and git-crypt will work transparently for all users since they get the new symmetric key when they pull (encrypted with their asymmetric key).

> Version control is pointless

git-crypt solves this for local diff operations. for anything web-based like git{hub,lab,tea,coffee} it still sucks.

> - Unless you are really careful, just one time forgetting to encrypt the vault when committing changes means you need to rotate all your secrets.

With git-crypt, if you have gitattributes set correctly (to include a file) and git-crypt is not working correctly or can't encrypt things, it will fail to commit so no risk there.

You can, of course, put secrets in files which you don't chose to encrypt. That is, I suppose, a risk of any solution regardless of in-repo vs out-of-repo encryption.

for 1), seems like you could do a proxy encryption solution.

edit: wrong way to phrase I think. What I mean to say is, have a message key to encrypt the body, but then rotate that when team membership changes, and "let them know" by updating a header that has the new message key encrypted using a key derived using each current member's public key.

Re 2 you can implement a custom Git diff tool, and so (with the encryption key) see what's changed, straight from `git diff`

Here's another one:

- using a third party tool to read and store credentials is an attack vector itself.