Math and cryptography don't care about a sheepish new employee (thankfully). The fact that leaked secrets will cause trouble is not mitigated by git forgetting a deleted commit. It is only mitigated by revoking that secret and creating a new one and not leaking it. So if a sheepish new employee fails to revoke them, why blame git or any other system? We have contracts, insurance and then criminal code for people who fail to follow protocols.

> So if a sheepish new employee fails to revoke them, why blame git or any other system? We have contracts, insurance and then criminal code for people who fail to follow protocols.

Because you won't know that a protocol isn't being followed. Your contracts, insurance, and criminal code won't cause you to realize that an employee caused an infosec incident if they don't tell you (and neither will your math and cryptography). And the more you threaten use of the criminal code, the less likely people are to admit that they made a mistake.

You can either build defense in depth (e.g., regular secret rotation, policies on use of GitHub in the first place or better yet automation that only pushes publicly after internal review, DLP via a corporate MITM, segregating your open source dev from your secret dev, etc.) or you can let your single defense get breached and have no idea.

The criminal code? I doubt there's anything in there that criminalizes a failure to follow an employer's secret revocation policies.

No, I wasn't referring specifically to this case. Generally, if people don't "follow the protocol", we have criminal code. If machines don't follow protocol, they end up with wrongly decrypted garbage data. It was to highlight the point that we have different measures to deal with people than we have with computer security, because math cannot prevent people from deviating from their protocols.

No need for any git-blame, the blame lies in GitHub not making this feature optional and more known. So well known that a noobish employee is aware of it, so that they do not feel like they are "safe" and no longer need to alert management about their error.

Contracts, insurance and criminal code are responsive measures, not preventative measures. Security is preventative, not responsive.

> the blame lies in GitHub not making this feature optional and more known.

Which feature are you meaning should be optional and more known?

In either case, the secret is already out whether the user wants to admit to it or not

But in one case, damage is mitigated because the sys admins didn't assume everyone is infallible and strictly adheres to protocol.

The correct way to deal with fallibility in this situation is to make it feasible to change secrets when they leak, not pretend they weren't leaked.

That doesn't prevent someone from not following protocol.

It's not their job to prevent that.

It is a sys admin's job to mitigate damage from security leaks and to introduce hardened, fault-tolerant security paradigms.

You are just hacking the leaves. Once the secret is posted. It is public, it has multiple copy elsewhere on the internet. Even if you delete there is a copy kept somewhere on the internet -- and that's not an assumption. For example, iirc, Github copy is dumped to google every some-x-time.

Hmmm, it seems like having layered security, where accidentally exposed credentials aren't automatically "game over" would be better than not.

Not sure how practical that is to implement for every technology, but for many it could probably be done.

Seems like a time+money vs risk trade off thing.

Is it mitigated? Once it's leaked you can't force everyone who may have captured it to delete it. So GitHub deleting it doesn't solve the problem.

The definition of mitigation is to make something less severe. Yes, GitHub making this policy as clear as possible and allowing controls to toggle it per-repository or per-account mitigates the problem.

I agree with the general statement about security absolutism (it's often very dumb and irrational), but in ths case in particular, most keys are swept from GitHub within seconds of being pushed, so the additional harm of not pruning those commits is very low. Data loss concerns are probably a much larger source of harm to weigh against it.

Well now I would say that I'm not interested in most keys, and I am interested in figuring out how to mitigate damage from the rest of them. You only need one key to get inside.

99% coverage is not good enough from a security standpoint, not when we can achieve 100%.

Simply, this functionality should be transparent and toggleable.

deleted

I think you're confused about what absolutism means. Just because I want 100% coverage when achievable does not mean I am being absolutist.

Yes and this is why Github handicapped their search so much.

But at the end of the day, any secret you post publicly is compromised.

That's a very poor reason to not have good searching functionality considering the uses far outweighs the potential risk. I highly doubt it's the case.

I'm 90% sure it is.

GitHub had great search, then they took it down when they found people we're scraping credentials with it, then they had bad search. I'm connecting the dots.

Thankfully the guys over at Sourcegraph feel differently about how searchable projects should be.