Hacker News Reader

Comment by bob1029 | Hacker News Reader

I am curious if someone can elaborate on the scenario in which one is accidentally committing secrets to source control.

For us, anything that would be a "secret" is stored in a SQLite database that sits next to the executable. In many cases, these secrets would additionally be encrypted with platform-specific techniques such as DPAPI. None of these databases are under source control and would be ignored upon commit.

If we want to load a secret into our application, we have to use an administrative web interface exposed by the application in each required environment. We view the management of secrets and other parameters as an important feature for our product and have built tooling up accordingly. Non-developers are able to manage secrets in our software, and we are actually trying to make this mandatory for compliance reasons.

View on HN

It's common (for novices/experts who are in a rush ) to accidentally commit AWS keys for dev environments, or other API keys (e.g. Mailchimp) or other secrets (2FA, SAML certs etc).

We all know how to do it right, but particularly early on in a project it's easy to test something with a hardcoded API key, then forget and commit it.

Picking a framework that makes this a less obvious choice (e.g using a .env file that's already in gitignore by default) helps a lot here.

So, what's to prevent a developer from also skipping over proper application of this hypothetical URI scheme if they are in a such rush? It seems like this is a similar level of pedantry that would be disregarded if one were in a hurry.

AWS, for example, could start issuing their tokens with this prefix. The hypothetical inexperienced/rushed developer is a consumer of the service, not an issuer of tokens.

Cloud services and other third party software starting to generate and require bearer tokens in this format.

It will be easiest for developers in a hurry or without knowledge to simply copy and paste these third party strings.

(Pedantry is only required when writing their own software to generate bearer tokens, not even using a library or framework, and developers rarely do that, especially the kinds of things written in a rush.)

The idea is that people issuing tokens (e.g. AWS, Mailchimp etc) in my example would follow this.

This would then allow other tools (e.g. git, GitHub, pre commit linters, frameworks) to flag this as a problem, either with a warning or an error, depending on the tool.

The idea is that then the novice/rushing expert is prevented from this easy to make mistake.

A common situation for this is when people put a Github "personal access token" in a dotfile and then store all their dotfiles on Github.

https://docs.github.com/en/github/authenticating-to-github/c...

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 populations.

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[1] 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?

[1] https://github.com/Yelp/detect-secrets

Reply on news.ycombinator.com