| ▲ | Ciantic 4 hours ago |
| I think every API key system should have endpoint "invalidate_api_key" this way whitehat hackers or the party who stored them could invalidate all keys in the case they leak. Now it is race against the time, and everybody got email, and everyone must act themselves. |
|
| ▲ | Tiberium 4 hours ago | parent | next [-] |
| It actually is a thing, although indirectly in a hacky way! If you push keys from GitHub secret scanning partners to a public repo or a gist, they get sent to the partner who (usually) instantly revoke them. So if you want to help someone, just make a public gist with the key and delete it like 15 seconds later, it'll be enough. https://docs.github.com/en/code-security/reference/secret-se... has a table with the active partners |
| |
| ▲ | Ciantic 4 hours ago | parent [-] | | Only responsible thing in this case would have been for OpenCode people to invalidate all keys. But I guess it is not that straightforward if Anthropic/OpenAI etc don't have endpoint for it. | | |
| ▲ | ameliaquining 4 hours ago | parent [-] | | There's no self-serve endpoint, but OpenCode could send the inference providers the leaked keys and ask for them to be revoked, which is a thing the inference providers can do. It's possible that this'll happen, apparently remediation is still in progress. |
|
|
|
| ▲ | orf 3 hours ago | parent | prev [-] |
| That just turns a credential leak into a denial of service - one that can be triggered from anywhere. |
| |
| ▲ | shepherdjerred 2 hours ago | parent | next [-] | | In this case you'd probably prefer your key to be disabled rather than spending $$$ on tokens for everyone else | | |
| ▲ | orf 2 hours ago | parent [-] | | Think that through - the person who stole the key has the decision to use it or revoke it through this hypothetical system. If they are acting maliciously, they will take the choice that most hurts you and/or benefits them. If the key is useless to them and revoking it hurts you, then they would do that. If the key wasn’t useless to them, then… they would just use it and not revoke it? | | |
| ▲ | asdfaoeu an hour ago | parent [-] | | It for whitehat third parties who discover unprotected keys obviously people intentionally stealing keys will not revoke them generally. | | |
| ▲ | orf 34 minutes ago | parent [-] | | And the whitehack hackers finding keys should do what, exactly? Unilaterally decide they should be revoked, without contacting the owner? And that’s not malicious? |
|
|
| |
| ▲ | flaunf221 2 hours ago | parent | prev | next [-] | | Not any more than any other public endpoint service exposes.
This revocation endpoint can be protected by auth too. Use API key that you're revoking in auth. | | |
| ▲ | orf 2 hours ago | parent [-] | | How does that make any sense? | | |
| ▲ | flaunf221 2 hours ago | parent [-] | | I see now from another comment you thought about denial of service for service that leaked key. And I thought about mass leak resulting in DDOS onto API provider. Wrong guess from me. |
|
| |
| ▲ | max__dev 2 hours ago | parent | prev [-] | | Yes. Is this a bad thing? | | |
| ▲ | orf 2 hours ago | parent [-] | | Of course it is? A key for some weather API getting leaked isn’t the end of the world, but having it revoked and breaking your weather app is. |
|
|