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

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 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.

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.

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.

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

Exactly; you should fully expect the NSA to have a copy of these logs as well. It can be very valuable to have secret keys from companies in adversarial countries (including your own).

Example, there's an ICE reporting app now where people can anonymously report ICE sightings... but how anonymous is it really? Users report a location, that can be cross-referenced with location histories and quicky led back to an individual. There may be retaliation to users of this app if the spiral into authoritarianism in the US continues.

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.

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.

Right, so, some activists and freedom fighters have been doing stuff in environments they know to be hostile for a long time, while the US has just started growing some movements like that after a hiatus from sometime in the seventies and eighties until somewhat recently.

For now they're going to be making a lot of basic mistakes but eventually they'll grugq up and learn from people that are already used to dealing with the violence of their government.

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.

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.

Repo secrets are just stored on someone's computer and they obviously have the keys. This is what I mean.

Same for your vault. The vault might be encrypted, but at some point you have to give the keys to the vault.

Your secrets are not safe from someone if someone needs them to run your code.

> Your secrets are not safe from someone if someone needs them to run your code.

This is true. I don't disagree with that or you're assessment of repo secrets.

My comment was in the context of the grandparent committing secrets to a private repo which is a bad practice (regardless of visibility). You could do that for tests, sure (I would suggestion creating random secrets for each test when you can), but then you're creating a bad habit. If you can't use random secrets for tests repo secrets would be acceptable, but I wouldn't use them beyond that.

For CI and deploys I would opt for some kind of secret manager. CI can be run on your own infrastructure, secret managers can be run on your own infrastructure, etc...

But somewhere in the stack secret(s) will be exposed to _someone_.

I like to encrypt secrets with a master secret stored in a TPM. This makes it impossible to accidentally leak the secret.