←back to thread

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

(trufflesecurity.com)
199 points elza_1111 | 1 comments | 03 Jul 25 06:44 UTC | HN request time: 0.22s | source
Show context
ggm ◴[03 Jul 25 07:13 UTC] No.44452457[source]▶
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.

replies(3): >>44452527 #>>44452528 #>>44452799 #
volemo ◴[03 Jul 25 07:27 UTC] No.44452528[source]▶
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.
replies(2): >>44452555 #>>44452635 #
gghffguhvc ◴[03 Jul 25 07:31 UTC] No.44452555[source]▶
The person who leaked it and the person/team that can rotate it might be in different silos or timezones etc. Rewriting the history is prudent but not sufficient.
replies(1): >>44452858 #
orthoxerox ◴[03 Jul 25 08:23 UTC] No.44452858[source]▶
That's why key revocation, like credit card blocking, should be a separate service that is available 24x7. Like, if you know the value of an AWS token, this should be sufficient data for you to call an AWS API that revokes it.
replies(1): >>44453158 #
1. badmintonbaseba ◴[03 Jul 25 09:18 UTC] No.44453158[source]▶
That doesn't help if revocation, without renewal means immediate outage.