Closed gingerlime closed 3 months ago
One way that ejson mitigates this is that decryption fails if there are any encryptable but unencrypted keys. It's not perfect, since it does still result in those secrets being committed, but at least people become aware quickly and the key can be rotated quickly.
I thought about encouraging a pattern like that, but ended up preferring the simplicity of one file. There may be a better solution though.
ejson looks great, but I'm slightly worried that developers might add an unencrypted secret and forget to encrypt it before committing / pushing. I guess we can ask them to add a git hook, but that's also easy to forget, or if you move your dev environment and forget.
I wonder about ways to avoid this. Perhaps having the encrypted file with a different name from the unencrypted one, and
.gitignore
ing the unencrypted one and only committing the encrypted version? instead of using the same file.