Secrets in the repo is actually something I've seen for a long time, and there's not much tooling necessary for it beyond just shelling out (yes, I know) to gpg

Secrets in the repo is actually something I've seen for a long time, and there's not much tooling necessary for it beyond just shelling out (yes, I know) to gpg in your deploy scripts. I saw this on CVS-based projects very early in my career, which then fizzled out as the "12 factor style" (secrets in ENV vars) took over. Can I ask what the modern solution for this is? Also: > If code changes need peer reviewed, how so configuration values don't get treated at least the same way? The easy answer to this is a CODEOWNERS file, with the app code being owned by the devs, and the config being owned by ops. But again, not sure how to do this for secrets without their being plaintext in the repo. Do any code review tools support encrypted content?