Presumably someone could have added a key, done evil, then removed the key. Evil includes all sorts of interesting things, like checking in code under the name of an existing contributor. This could potentially be really subtle and would be difficult to find in an audit later.
Deleting the keys afterward isn't really a key (heh) part of the attack, just a nice way to cover your tracks afterward. Enough accounts have multiple expired or forgotten keys to make the mere presence of multiple keys and potentially some unknown keys not always an absolute indicator of compromise, too.
It's likely that your ssh key only authenticates your account anyway. If that were the case, you could change your key to a different account, make a change, and then change it back and no one would be the wiser (though any logs demonstrating an identical key across users would identify it, but unlikely they exist and in a form worth pursuing). Security is hard.
Ah, I didn't check that. It still means a bad key could have been used for evil, just that there would be clear evidence left behind.
The issue is that I've had lots of ssh keys, and might not have my fingerprints for all of them. If I see a bad fingerprint, it's entirely probable it's just an old key of mine from an old laptop, cellphone, script, or whatever, and NOT an attacker's key.
But, in light of this attack which you revealed, now any account which contains keys which aren't 100% accountable could have been compromised by an attacker. (in fairness, someone who stole the github user password could have done the same thing too, but that's an obvious attack route)
I thought git itself provides authentication and integrity? In fact, if someone modifies the history of a branch that will raise all sorts of red flags the next time a legitimate user pushes.
Not modifying stuff on disk outside git, but using substituted keys to masquerade as a legitimate user and contribute evil code. It leaves an audit trail, but means you need to audit all contributes even those ostensibly from project owners.
Not really. If you make a new commit on top of the history, then nobody will notice unless you sign every commit (which i don't think is common practice).
Only modifying (existing) history will cause git to complain.
Presumably someone could have added a key, done evil, then removed the key. Evil includes all sorts of interesting things, like checking in code under the name of an existing contributor. This could potentially be really subtle and would be difficult to find in an audit later.
(Remember the stink over OpenBSD potentially having backdoors in the IPsec stack, revealed in late 2010? http://blogs.csoonline.com/1296/an_fbi_backdoor_in_openbsd)