[siliconc0w]

The problem is you need some repository to store this information and it's incredibly helpful to store the configuration along with the code.

If someone has access to a shared secret and then shouldn't you should assume the secret is now compromised and rotate it. Rotating the keys doesn't solve this problem.

[tptacek]

No. If that were the case, there would be no purpose to rotating keys. The problem is that despite rotating keys, your old crypto keys have permanent access to secrets, because the old ciphertexts are by default retained in the git history.

It's a bad idea to store secrets in any form in your source code repository.

[startling]

I think what grandparent and others are saying is that you also revoke the secrets contained in the ciphertext, e.g. if it's an AWS key you would revoke that AWS key on AWS's side as well as encrypting new secrets with a different encryption key.

Obviously this is a huge hassle and isn't easily done with all kinds of secrets (which is what I think you're getting at?). But it's also often necessary.

[tadfisher]

> The problem is you need some repository to store this information

This doesn't have to be a Git repository, nor does it have to be the same repository as the code which uses the secrets.

> it's incredibly helpful to store the configuration along with the code

It's helpful, but ultimately means that the ciphertext is potentially available to the world and existing keys may decipher it in perpetuity. Thus this is not a recommended tradeoff to make.

[Aoreias]

It is helpful to store configuration with code, but you don't have to include secret values in your code. It's much better to use a purpose built service like credstash[0] to store secret values while you keep the name of the secret and (possibly) version in a repo with your code.

[0] https://github.com/fugue/credstash