[p-e-w]

Same as with any other decision: Do a cost/benefit analysis of whether the security risk created by rotating the key is actually outweighed by the security risk of doing nothing, taking into account logs that should tell you whether the exposed key was indeed accessed by unauthorized parties.

To be 100% clear: Both courses of action come with associated security risks. The problem is not choosing one course of action over the other, the problem is thinking you can just skip the cost/benefit analysis because the answer is somehow 'obvious'. It's not obvious at all.

[johngalt_]

No, you cannot keep using an exposed key. You must replace it. There is no cost/benefit analysis needed in this situation.

[p-e-w]

Wrong. A CBA is always needed. If the potential damage from MITM attacks made possible by rotating the key is greater than the potential damage from a rogue key multiplied by the likelihood that someone actually accessed the key, then it is wrong to rotate the key. It's that simple.

The only way a CBA would be unnecessary is if rotating the key didn't have any security risks. But it does.

[eyelidlessness]

Here I’ll do the CBA:

- if they have evidence that the key was exposed to one person, even with zero usage of the key, failing to rotate the key is tantamount to knowingly accepting widespread compromise at a potential attacker’s whim. At GitHub’s scale, that’s untenable.

- rotating the key is the only correct reaction to that

- they should have better communications in place to help users mitigate MITM

- there really isn’t an option, because they’re critical infrastructure; I’m glad they know that and acted accordingly

- on principle this speculation makes sense, but understanding the threat makes it moot

- you hopefully know that, and it’s good to insist on thoughtful security practices but it’s important to also understand the actual risk

[hnlmorg]

There is a MITM risk regardless of whether they rotate the key. Except one is a one time risk and the other is a perpetual risk.

Thus rotating is the only logical course of action.

[p-e-w]

Only if you know for certain that the key has been accessed by a third party.

If you don't know for certain, you have to factor in the likelihood that it has been, and at that point, the two risks aren't equal anymore so that logic doesn't work.

[msm_]

Are you arguing for the sake of arguing and technical correctness or do you actually believe Github shouldn't rotate their key in this situation?

[unionpivo]

What if you don't know for certain ?

You just ignore it and hope for the best ?

Only if you are certain (and better be really sure you haven't missed any cache/cdn, temp files backus etc.) it wasn't accessed you do nothing.

[lazide]

It was publicly exposed, and if they are making this announcement it’s essentially guaranteed they can’t rule out it was accessed.

[xign]

What? This is a terrible way to reason about risks in general. If you don't know for certain, you should assume the worst case scenario, especially since it's impossible for you to calculate the probability distribution of the likelihood of a leak.

You should only keep moving along without key rotation if you know for 100% certainty a leak didn't happen and no one accessed the key (not theoretically impossible if they had the server logs to back it up), but anything minus that and you have to assume it's stolen.