Signed code isn't always enough

Computer security specialists frequently point to digitally signing software as a way to prevent an attacker from replacing software with a malicious version. (Of course, the signatures themselves are of no value unless they're checked - with a chain of custody starting as far back as you can, which is what some of the Microsoft Trusted Computing stuff is about.) The lack of digital signatures on software in voting machines is frequently (and accurately) listed as one piece of evidence that the voting systems are insecure.

But more importantly, the signature is only of value if the bad guy can't create their own signature that looks valid. And it appears possible that something like that may have happened with Red Hat Fedora. Red Hat announced that "some Fedora servers were illegally accessed...
One of the compromised Fedora servers was a system used for signing Fedora packages. ... we have high confidence that the intruder was not able to capture the passphrase used to secure
the Fedora package signing key."

They then go on to note that they're replacing the signing key out of an abundance of caution, and everyone will have to update their systems to understand the new key. But it's very hard to know for sure whether the signing key was used during the compromise period - bad guys are very good at covering their tracks.

The bottom line is that code signing just shifts the weak spot for attackers - instead of just trying to change the code on the server before it gets downloaded, they focus on accessing the signing key. And the real safeguard isn't the length of the signing key (which is presumably long enough to prevent brute-force attacks), but rather the quality of the passphrase used to unlock the signing key, the set of people (or systems) that have the signing key, and the safeguards around changing the key.

We should keep doing code signing, but as with all security measures, recognize that it's a defensive measure, not a panacea.