4 ms·
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 tro
by toboraton 11y ago
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.
- hlandau 11y agoIndeed. 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.)