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

Funny thing, we had a similar issue with one of our deployement in the past. It's similar to leaking accidently your password into bash history. Happens more than it should.

I guess it's possible to delete these forever as by deleting the entire repo and re uploading. As long as there are no forks.

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

Git doesn’t clone those orphaned refs though right?

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.

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.

Different employees in the company have different permissions. If an employee with a lot of access commits a secret, then employees who shouldn't have that much access can take the secret and use it.

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.

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.

Many years ago at my first job after university, I accidentally committed a private key into our internal Git repository. We removed it, because we could not completely rule out the possibility that this repository would be made public to a customer, or to the world, in the future. I think we used filter-repo to get the key out of everywhere.

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.

Abusing? I thought this is exactly what envvars are for.

I encrypt any secret strings with a master password that lives either in a TPM module or a file named MASTER_SECRET that is absolutely not added to the Git repo. My standard new project script adds this file to .gitignore and I use a pre-commit hook that stops this file from being committed by accident.

And can we talk about the predatory pricing model? In AWS one secret service prices a secret for 0.4 dollars a month. I was appalled when I first saw it, are you going to charge me 5$ a year for storing my 12 bytes?

If you push a secret publicly, you should consider it leaked. On GitHub, you have 5 minutes on a non-watched repository (due to the delay) and less than 30 seconds on a watched repository to revoke it before it's been cloned and archived by a third-party. Whether that party is malicious or not, rewriting the Git history will not change anything that the secret is leaked. And you can already rewrite the Git History and garbage collect commits that aren't part of the tree anymore on most providers.

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.

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

Concerning.

It's interesting research, but will Truffle Security use the email addresses for lead gen or marketing purposes, like how they mined users' pingbacks from their XSS Hunter fork for stats?

https://portswigger.net/daily-swig/new-xss-hunter-host-truff...

That’s a common hurdle when trying to access files like this. You might want to check out LeadsApp—they can help organize data without needing a Google login. It made sorting through similar issues easier for me.

Assume you can't, even if you contact support someone will have archived it by the time anything gets done. Murphy's Law of Internet Data Storage applies: if you post something to the internet it'll be public forever; if there's something on the internet you remember seeing once and want to find again it will have link-rotted and been lost forever.

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.

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.

There are already people scanning git repos for Bitcoin/Ethereum/crypto keys and exploiting them immediately.

"70% of secrets leaked in 2022 remain valid today"[1] is a quote that should help understand the situation.

[1] https://blog.gitguardian.com/the-state-of-secrets-sprawl-202...

this is specifically deleted commits, which even if locally are deleted, are not so on GH, hence why he was able to find deleted .envs etc.

I'm surprised that it's not more. I couple of years ago I spent a few months basically github dorking for leaked api keys and made more than that.

Congrats on commenting without reading the article.

I think you mean "rotate the keys"

Had it correct in the first two points, then contradicted yourself with the last. Rotate your secrets.

The problem here is that GitHub keeps the ref logs even for commits that no longer exist.

I don’t see how BFG helps here

Git does forget, it has a gc mechanism specifically for forgetting.

GitHub can't use the native git gc, and apparently doesn't have their own fork-aware and weird-cross-repo-merge-aware gc, so they might just not have built a way to track which commits are dangling.

But that's not obvious at all.

Git is not point in time backups. It is versioning.

You are free to organize your version history as you fit, and you can certainly rewrite history.

The only issue you might have is signed commits from collaborators, that you can not resign.

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