Code signing's downfalls outweigh its perceived benefits. It's the same principle as certificate authorities, and all it means is that the signer gave a "seal of approval" for the software. When a malicious program manages to thwart the checks and it ends up being signed, people who use this program will end up distraught because they placed so much trust in a "safe" mechanism that turns out only to dish false reassurance. I don't know the requirements for code signing, but it could also very well place developers in Microsoft's hands just so they can showcase their code as "trusted". It ultimately deters people from using unsigned code under the false impression that unsigned (or self-signed) code is by default insecure compared to signed code.

I'm going to say that this is naive open source zealot bullshit.

Code signing is what is keeping the FBI out of the iPhone. It's how we will keep malicious trojans and other kinds of advanced persistent threats out of the ecosystem in the future.

If you think code signing is a bad idea, then you aren't thinking about the post Snowden security landscape.

Now, what most code signing systems fail on today is the ability to control which keys you trust. Ideally you should be able to manage trust delegation.

But, in the future, we will think of running unsigned code like we currently think of protocols like FTP, telnet and rsh - built for a simpler, more trusting era.

Indeed. Code signing is a perfectly valid technique, and useful, but device owners must be able to control the root of trust. It's when code signing is used to create a system of manufacturer, rather than device owner control that is the problem.

Authenticode seems okay so long as executability doesn't depend on it. But there's a risk Microsoft might interpret it as a vote for "require signing for EXE files" (because the more people use it, the less developers to complain if they require it). If this started to look likely one could always use GPG.

Though in practice this shouldn't be possible... there is a very, very long history of binaries which are no longer updated and never will be, so introducing such a restriction is essentially impossible. (Of course, there's no secure way of determining binary date, so grandfathering is impossible.)

> Also, I'm not aware of a case where a corporation used code signing to keep a legitimate developer/company out of a platform for non-malicious reasons.

See iOS and flux. GBA4iOS is in a similar boat, but they managed to get around it via a mechanism intended to allow enterprise side loading.

Ios?