We agree that if you store secrets in a repo, any time you change the encryption key, you have to go and purge the underlying secrets. We disagree that this is intuitive or that shops do this reliably.

We should be able to agree that not storing secrets in your repo dodges all these problems nicely.

Well, I disagree. It doesn't matter where you store them, repo or not: even if they're not in a "repo", they're stored somewhere, and when you revoke access from someone to that somewhere, you still have the same problem: the party that you're revoking access from had access at one point. For all you know, they copied the secret while they had access. You can't "revoke" information from someone's mind: you MUST rotate the secret to accomplish that.

If anything, I like the git repo idea b/c — presuming that the repository stores a history of who had access to what, when — it removes the question of whether you need to rotate a secret. You can look at the history, and if the secret didn't get rotated when access was removed or at some time afterwards, you know you're not secure.

Compare that to say, a random file somewhere, say on a deployment node in deployment code, or alongside that code so as to keep it out of a repo, that just keeps the latest copy of the secrets, where one doesn't know when access was revoked. Do the keys need rotation?

If you use a purpose built storage though then you can deny access to the actual keys to just about everyone, so if a developer leaves then they won't have the keys, and if they do you'll know because it will have a built in audit trail. And in many cases you never have to release the key from the purpose built store because it takes in crypto text and gives out plain text without ever revealing the key to the user.

They'll have their own key, which will be revoked from the store, and they might have a single key that machines use to access the store. You should be rotating that machine key all the time anyway, so rotating once more when a dev leaves isn't a big deal. It's also much easier than rotating all of your actual keys, which in many cases is generated by a third party that may make such a thing very hard.

What you are describing is how to remove _access_ to the secret. The issue here is, that the former employee still has _knowledge_ of the secret. Hence you have to rotate the secret.

Plenty of companies choose to accept the risk that an employee might have memorized a secret, but not accept the risk that the employee's secret-encrypting-key might leak at any point for the lifetime of the repository.

Obviously, nothing you do w/r/t secret storage is going to resolve the problem of what's in your employees' heads.

If a developer leaves they'll still have the plaintext of the keys from when they were working for you. You have to change your secrets at that point.

In this case state of access control is stored along with code/secrets. The problem is that ACLs, secrets themselves and code change independently of each other. This only works if you assume no downgrading and homogeneous versioning across all instances.

You're forgetting that if I have been storing all of the encrypted traffic all along and then get access to the keys I can unlock all of the history too. Once a secret is out of use it should be purged completely. This is why secrets should be stored on ephemeral storage if at all possible. This is however pretty advance for many people.

This is solved with perfect forward secrecy: https://en.m.wikipedia.org/wiki/Forward_secrecy