Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I scanned all of GitHub's "oops commits" for leaked secrets

trufflesecurity.com

Post reply on HN
Print view View original

31–40 of 117 posts

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#31

Post by froobius »

UnreachableCode wrote: post #27

What I've never understood is, how is this an issue with private repos? Aside from open source projects I can't see the problem with accidentally doing this, even though it is a smell.

It's a bad idea...

- commit secret in currently private repo

- 3 years later share / make public

- forget the secret is in the commit history, and still valid, (and relatedly, having long-lived secrets is less secure)

Sure that might not happen for you, but the chances increase dramatically if you make a habit of commiting secrets.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#33

Post by sunbum »

matsemann wrote: post #11
raesene9 wrote: post #7

An interesting look at one of the consequences of using git and public repo's. Does leave me wondering how long before someone has a setup which detects and tries to exploit these in real-time, which feels like it could be nasty. Also a challenge with these posts is they were unlikely to have been able to contact all the affected developers who have got exposed secrets, meaning that any that were uncontactable/non-re…

There are hundred of setups like that already. If you push an AWS key or similar publicly you may have a bitcoin miner or botnet running on your cloud in matter of minutes.

Nope. Because if you push an AWS key then it gets automatically revoked by AWS.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#34

Post by tobyhinloopen »

ggm wrote: post #6

Maybe a default secure delete option could be made a lower bar event? Checkout to event, commit in clean state with prior log history, overlay the state after the elision and replace git repo? When I had to retain log and elide state I did things like this in RCS. Getting date/time info right was tricky.

Anything pushed is to be considered leaked. You might as well leave the commit in and invalidate the secret.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#36

Post by tobyhinloopen »

jbverschoor wrote: post #22
volemo wrote: post #14

Earlier quoted context omitted.

If something got out to the internet, you won't get it back. There is little point in rewriting repo history if you have already made a secret public. Just change the secret as soon as you can.

Yet people complain that Netflix/Youtube pull certain content ;)

Yes, because paying customers will have the content removed but it will continue to be available for pirates.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#37

Post by Cthulhu_ »

edverma2 wrote: post #23

All devs should run open-source trufflehog as a precommit hook for all repositories on their local system. It’s not a foolproof solution, but it’s a small time investment to get set up and gives me reasonable assurance that I will not accidentally commit a secret. I’m unsure why this is not more widely considered standard practice.

Pre-commit hooks are client-side only and opt-in; I've always been a big proponent of pre-commit hooks, as the sooner you find an issue the cheaper it is to fix, but over time pre-commit hooks that e.g. run unit tests tend to take longer and longer, and some people want to do rapid-fire commits instead of being a bit more thoughtful about it.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#38

Post by yard2010 »

froobius wrote: post #31
UnreachableCode wrote: post #27

What I've never understood is, how is this an issue with private repos? Aside from open source projects I can't see the problem with accidentally doing this, even though it is a smell.

It's a bad idea... - commit secret in currently private repo - 3 years later share / make public - forget the secret is in the commit history, and still valid, (and relatedly, having long-lived secrets is less secure) Sure that might not happen for you, but the chances increase dramatically if you make a habit of commiting secrets.

In a large messaging app I worked for we self hosted a gitlab instance for this exact reason. I thought it was over the top but now I get it, you can never be too sure.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#39

Post by dspillett »

UnreachableCode wrote: post #27

What I've never understood is, how is this an issue with private repos? Aside from open source projects I can't see the problem with accidentally doing this, even though it is a smell.

Anything that makes the repo less private later (deliberate public release, hack (not just if the repo bit of anything that can connect to it), etc) means the secret is now in the open.

Always cycle credentials after an accident like committing them to source control. Do it immediately, you will forget later. Even if you are 100% sure the repo will never be more public, it is a good habit to form.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#40

Post by whyever »

oefrha wrote: post #30

> GitHub keeps these dangling commits, from what we can tell, forever. Not if you contact customer support and ask them to garbage collect your repo. What I do when I accidentally push something I don’t want public: - Force push; - Immediately rotate if it’s something like a secret key; - Contact customer support to gc the repo (and verify the commit is gone afterwards). (Of course you should consider the damage done…

If you rotated the secret, why do anything else? I don't think there is any potential further damage (except maybe reputational).
Post reply on HN