Live data from Hacker News

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

trufflesecurity.com

51–60 of 117 posts

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

#51
post #5

Earlier quoted context omitted.

What specific property of git mandates a website to not clean up those dangling commits?

Git has no de jure hierarchy of repositories. We de facto treat the GH repo as the primary one (and call it "origin"), but mechanically it's a peer repo. Even though it lets other repos push it around a bit and obeys commands like "change the branch to point to another commit", there are no commands to force it to delete the data.

> Even though it lets other repos push it around

So there is hierarchy

> there are no commands to force it to delete the data.

That's just the current state, the question was how git prevents "de facto" deletion on a server? How is it anti-git to ask the server to execute git garbage collection commands, for example?

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

#53
post #40

Earlier quoted context omitted.

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

Anyone who puts weight on digging through a project to see if they've ever leaked a secret is guilty of encouraging an antipattern-- the guaranteed outcome is you'll have an organization petrified of shipping anything, in case someone interprets it as bad or a security risk, etc.

You can see it that way, however, there are automated tools to scan for secrets. Even github does it. In my opinion, this educates the developers to be more careful and slightly more security oriented, rather than afraid of shipping code.

I would also like to remind that a leaked AWS secret can cost 100Ks of $ to an organization. And AWS won't help you there.

It can literally break your company and get people unemployed, depending on the secret/saas.

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

#54

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.

If I'm honest, I don't know how much this happens at work, and even if it does it's not the end of the world. Just scratch the commit from existence. In my head, the people who accidentally share secrets are also the people who couldn't setup trufflehog with a precommit.

> Just scratch the commit from existence.

Unfortunately, that is impossible: https://trufflesecurity.com/blog/anyone-can-access-deleted-a...

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

#55
The thing that people miss out is Git is really a content addressed storage. This means all commits, even the ones not linked to any refs are still stored and addressable.

p.s: If you run OSS project, please use Github Advanced Security and enable Push Protection against secrets.

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

#56
post #47
post #29

Earlier quoted context omitted.

It's called private but actually shared with a very large corporation you don't control, likely running on infrastructure they don't control. Due to the CLOUD Act it's also shared with the US government.

Secrets gotta live somewhere. Are you supplying them every time you deploy or run CI?

Yes. Either via a secret manager (eg vault) or configured as repo secrets if that kind of infra isn't available.

https://docs.github.com/en/actions/how-tos/security-for-gith...

Never commit secrets for any reason.

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

#57
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…

Git doesn’t clone those orphaned refs though right?

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

#58
post #21

Maybe I missed it but the article doesn't mention the even easier way to see this: the activity tab. It has everything. Any force push to hide ugly prototype code is kept forever which annoys me. I wish we were able to remove stuff from there but the only way to do it is to email support it seems? Here it is for the test repo mentioned https://github.com/SharonBrizinov/test-oops-commit/activity

Where is that linked from? I've been using GitHub for years and never heard of this page.

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

#59
post #47
post #29

Earlier quoted context omitted.

It's called private but actually shared with a very large corporation you don't control, likely running on infrastructure they don't control. Due to the CLOUD Act it's also shared with the US government.

Secrets gotta live somewhere. Are you supplying them every time you deploy or run CI?

I'm not telling you what you should or should not do, especially not in the abstract. I commented on the deceptive terminology employed by a very large corporation with deep connections to rather distasteful activities and organisations.

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

#60
post #55

The thing that people miss out is Git is really a content addressed storage. This means all commits, even the ones not linked to any refs are still stored and addressable. p.s: If you run OSS project, please use Github Advanced Security and enable Push Protection against secrets.

Are you talking about the local branch and the local reflog?

I thought garbage collection should get rid of all dangling stuff. But even without that, I am curious if pushing a branch would push the dangling commits as well.

Post reply on HN