Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
This is a neat idea. I've thrown together a small Python library for working with these: https://github.com/Lexicality/secret-token
Unfortunately, there is tooling, and a subculture that builds tooling, that uses configuration files in the same directory as the source code.
Say you're deploying with cool-deploy-tool. cool-deploy-tool finds the password for the server by looking for a file called "Coolfile" in the project root. You have to create that file to use it. Now you have a footgun lying around.
I associate this stuff with the Ruby community, but it's spread far and wide, notably to the Node and Go communities, which i think have large Ruby emigrant communities.
As a prototypal example, consider dotenv, which began in Ruby:
https://github.com/bkeepers/dotenv
And has travelled to Node:
https://github.com/motdotla/dotenv
And Go:
https://github.com/joho/godotenv
Yeah, I'm not sure why this is such a problem. At work we tried out using [detect-secrets](https://github.com/Yelp/detect-secrets) for a while to make sure we didn't accidentally commit anything important.
It was a huge pain, it picked up nothing but false positives.
After a few months we decided that our pre-existing practices: have secrets passed to the app in environment variables which are set during deployment, and use fake secrets for test and dev, solved the problem in a much less painful way.
Is it so hard to keep real secrets separate from the source code?
If people are looking for a way to put encrypted files into git, you can use LockGit https://github.com/jswidler/lockgit.