I wouldn’t recommend this. What if GitHub’s token scanning service went down. Id...

jychang · 2026-01-14T23:01:09 1768431669

You're revoking the attacker's key (that they're using to upload the docs to their own account), this is probably the best option available.

Obviously you have better methods to revoke your own keys.

securesaml · 2026-01-15T00:06:48 1768435608

it is less of a problem for revoking attacker's keys (but maybe it has access to victim's contents?).

agreed it shouldn't be used to revoke non-malicious/your own keys

nebezb · 2026-01-15T01:53:05 1768441985

The poster you originally replied to is suggesting this for revoking the attackers keys. Not for revocation of their own keys…

securesaml · 2026-01-15T02:41:48 1768444908

there's still some risk of publishing an attacker's key. For example, what if the attacker's key had access to sensitive user data?

throwawaysleep · 2026-01-15T05:54:53 1768456493

All the more reason to nuke the key ASAP, no?

eru · 2026-01-15T04:19:11 1768450751

> What if GitHub’s token scanning service went down.

If it's a secret gist, you only exposed the attacker's key to github, but not to the wider public?

OJFord · 2026-01-15T09:08:40 1768468120

They mean it went down as in stopped working, had some outage; so you've tried to use it as a token revocation service, but it doesn't work (or not as quickly as you expect).

eru · 2026-01-16T02:01:00 1768528860

Sure, that's a valid worry. Though that's not all that different from a special purpose public token revocation service: they can also go down.

OJFord · 2026-01-16T17:26:40 1768584400

True, just more to rely on with the scanning too I suppose.