Never commit secrets into Git repos | Hacker News Reader

Never commit secrets into Git repos

datree.io

16 pointsgk112 comments

Or make sure your secrets are transparently en/decrypted with GPG using: https://github.com/AGWA/git-crypt if you really have to (and use https://rtyley.github.io/bfg-repo-cleaner/ to cleanup any history of commited secrets).

An .envrc file with https://pypi.org/project/keyring/#using-keyring also provides a nice solution for keeping secrets out of git for local development. Requires no central server, only your local key storage (eg: keychain for macOS).

> f you really have to (and use https://rtyley.github.io/bfg-repo-cleaner/ to cleanup any history of commited secrets).

Don't bother. If you push a secret: Do not pass go. Do not collect $200. Just rotate your secrets and move on. If you push your repo you should treat the contents as public information.

Correct, if you know it is public exposed. Our team had a private repo which we wanted to make open source inside our company without exposing the secrets stored there. In our case BFG saved us a lot of trouble and we could get this feature out quickly instead of postponing it while waiting to rotate all keys.

> Everything should be encrypted both in transit and at rest. When your secret is encrypted, it is not available to the attacker and you can cut off access and rotate the plaintext secret to remedy the situation.

Not sure how valid this point is. If the attacker has access to a production server, he had also access to all needed production keys. Encrypted or not.

Hashicorps Vault is great, but I'm amazed at how many of the answers to questions happen to be "use our product." Pretty heavy-handed commercial for Datree here.

> ALWAYS encrypt your secrets in transit and at rest

And the encryption secret for this is stored...how?

https://github.com/seletskiy/carcosa

git repositories are not somehow incompatible with encryption.

That sounds like a lot of work. I don't see any problem with committing secrets into git repositories if a) the git repo is not in the cloud, b) what the secret is used for is not in the cloud either.

I don't think it being in the cloud or not makes a difference. Applications that aren't in the cloud can still be broken into. Leaving things in source control just adds another surface for attackers to use to compromise your applications

> I don't think it being in the cloud or not makes a difference. Applications that aren't in the cloud can still be broken into.

So if the attacker has already broken into our corporate networks and can access the internal applications directly, what's to stop them from just examining the environment variables directly to get the secrets from there?

I don't understand the added value of Vault. We have secrets committed to internal GitLab where you need an LDAP account to even view/clone the repo. The secrets are used for internal applications that make calls to external APIs (like a weather service). If the attacker can gain access to the GitLab source, surely it's equally trivial to just examine the environment variables of the internal application itself since the secrets will be in plain text.

And if the secrets are not in plain text (i.e. you are passing the secret encrypted), then surely the attacker need only examine the source code (which we've established he has access to) to see how to decrypt the secret from the environment variable.

Seems like an impossible chicken and egg problem.

It’s not in the cloud but rather who can access it. If it’s local on your system and you were just going to have the secret sitting in a text file anyway, it’s not much of a change but otherwise you’re increasing that to everyone who can see the repo and making it much harder to remove it.

Those are manageable in some cases but if you’re safe from the beginning you never have to spend time on it later or wonder whether you’ve made a mistake in your calculations.

Reply on news.ycombinator.com