this post was submitted on 18 Aug 2024
74 points (97.4% liked)

Programming

17651 readers
488 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 2 years ago
MODERATORS
 

I know that pushing a commit with an API key is something for which a developer should have his balls cut off, but...

...I'm wondering what I should do if, somehow, I accidentally commit an API key or other sensitive information, an environment variable to the repo.

Should I just revoke the access and leave it as is, or maybe locally remove this commit and force-push a new one without the key? How do you guys handle this situation in a professional environment?

top 22 comments
sorted by: hot top controversial new old
[–] [email protected] 85 points 4 months ago (2 children)

Other answers have only called out rotating the secret which is how you fix this specific failure. After you’ve rotated, delete the key from the repo because secrets don’t belong in repos. Next look at something like git-secrets or gitleaks to use as a local pre-commit hook to help prevent future failures. You’re human and you’re going to make mistakes; plan for them.

Another good habit to be in is to only access secrets from environment variables. I personally use direnv whose configuration file is globally ignored via the core.excludesfile.

You can add other strategies for good defense-in-depth such as a pre-receive hook checking for secrets to ensure no one can push them (eg they didn’t install hooks).

[–] [email protected] 21 points 4 months ago

The smoking man clearly has engineered with humans before. Kudos for excellent advice.

[–] [email protected] 9 points 4 months ago (3 children)

only access secrets from environment variables

I kind of think this is a bad idea because environment variables can be read from anywhere and aren't designed to be secret.

But I'm not sure what a better solution is tbh.

[–] calcopiritus 13 points 4 months ago (1 children)

Storing them in files with correct permissions.

[–] [email protected] 3 points 4 months ago

also storing them outside of the webserver directory

[–] [email protected] 3 points 4 months ago

you’re not entirely wrong, but this is the current standard/accepted advice for local development - probably what we’re talking about given this thread is about git commits - because the chance of exploit via this mechanism requires local access… with such access, you’re pretty screwed in far more ways

[–] [email protected] 1 points 4 months ago

Sops, or OpenBao

[–] [email protected] 62 points 4 months ago (1 children)

Rotate the keys, the old one is on the Internet forever

[–] [email protected] 17 points 4 months ago (2 children)

This is the only answer. Git history is forever.

[–] SwordInStone -1 points 4 months ago (2 children)
[–] WhatAmLemmy 12 points 4 months ago

If you upload anything to the internet unencrypted, it's always best to assume it'll be publicly accessible forever.

[–] [email protected] -2 points 4 months ago

s/git/github please

[–] [email protected] 52 points 4 months ago

As others have already pointed out, you must rotate the key. I don't even put any restrictions on that. Once you have shared a secret in any way, it is no longer a secret. Don't try to avoid work, just because it is an inconvenience. Convenience is the enemy of security.

Rotating your key is not enough though. Verify that it wasn't used. API providers also often provide audit logs to show when credentials were used and from which location. If someone had your key only for a second, they could have used it to generate a new key you don't even know about. Audit!

[–] [email protected] 26 points 4 months ago

If you pushed to github, that key is there forever! (very few exceptions). Regardless, if you pushed it to any machine you don't own, assume it's compromised and rotate.

Anti Commercial-AI license

[–] [email protected] 21 points 4 months ago

If it's a publicly-accessible repo, then immediately revoke the key and leave it. Force-pushing isn't good enough because the old commit will still be tracked by Git until the garbage collector kicks in, and you don't have control over the GC on GitHub (not sure about other providers).

If it's an internal repo that's only accessible by employees, then you probably should still revoke it, but you've got more leeway. Usually I'd create a ticket to revoke it when there's time, unless this is particularly sensitive.

[–] [email protected] 15 points 4 months ago

You don't say if you noticed before pushing. If it's your last commit and not pushed yet, you can still amend your last commit.

[–] [email protected] 10 points 4 months ago
[–] [email protected] 9 points 4 months ago

Revoke, invalidate, rotate, blacklist, do whatever to make the key/information not usable for that system anymore. It's an "exploit" (but more a defining feature of git) to record everything because each link is dependent on the last thing and even old branches can be brought back and searched through.

[–] [email protected] 8 points 4 months ago

If you didn't push your changes yet, you can use git filter-branch to remove it from all your commits. If you already pushed (or figured out that someone committed and pushed a key), you can do the same with force-push, but also revoke the key.

[–] eager_eagle 3 points 4 months ago

howtorotate.com

[–] [email protected] 2 points 4 months ago

If it's a public repo, revoke the key (on your own/company repo it might not matter so much)

Then

  • git reset head~1
  • remove api key
  • git push - f