I suppose I can break it down another way.
Complexity introduces vulnerabilities.
Some complexity is necessary for the software to accomplish what the customer wants.
Some complexity is arguably necessary to protect the interests of the vendor. This is arguable because it varies between open source and proprietary software.
To me, it is upsetting when the code to protect the vendor's interests is where a critical security vulnerability exists. I don't think this is a controversial statement.
Cryptographically signed binaries are not used to manage licensing issues, they are used to make sure that no-one intercepts your download and replaces it with a malicious binary. It is absolutely essential that computer programs are signed or delivered through a secure connection.
Losing your signing keys will make the entire system jeopardized and new keys must be generated and securely transmitted (this is hard).
> To me, it is upsetting when the code to protect the vendor's interests is where a critical security vulnerability exists.
Yes, that would be upsetting if it were true. But it isn't. The whole system is in place to protect you, the customer.
The entire reason the attackers could use the certificate was because Microsoft left behind that functionality in the suite of software that allows enterprise customers to license their instances of Terminal Servers.
I am not railing against cryptographic signing as a concept -- what happened was Microsoft played fast and loose with their certificate chain in order to provide their customers with a way to prove that they had paid for software.
The certificate chain could have been a lot cleaner if that licensing bit wasn't necessary.
The chances of someone slipping in a backdoor in kernel releases are very slim.
But you can always get the source and build the package yourself. Can you do that with Windows?