Quite a lot of people raised their eyebrows the way ex-Red Hat developer Matthew Garrett made Microsoft the 'universal' controller of any desktops PCs running with UEFI secure boot. Though the intentions of Garrett were clear - to enable GNU/Linux to be able to run Linux on Windows 8 certified PCs with secure boot; it was clearly putting Microsoft in a very powerful position.

It's debatable what could have been the alternatives as supposedly no one tried and even the Linux Foundation gave in. The only hope is now with Google's Chromebooks which use 'free software or open source' core boot where you don't have to bend on your knees for Microsoft.

• Suggested story: Is Canonical running out of money?

That's old news.

The issue resurfaced when Red Hat developer David Howells sent Linus a pull request:

Can you pull this patchset please?

It provides a facility by which keys can be added dynamically to a kernel that is running in secure-boot mode. To permit a key to be loaded under such a condition, we require that the new key be signed by a key that we already have (and trust) - where keys that we "already have" could include those embedded in the kernel, those in the UEFI database and those in cryptographic hardware. <more here>

To which Linus responded:

Not without a lot more discussion first. Quite frankly, this is f*cking moronic. The whole thing seems to be designed around stupid interfaces, for completely moronic reasons. Why should we do this? I already dislike our existing X.509 parser. And this makes the idiotic complicated interfaces, and now it goes up to 11.

That's when Garrett joined the thread stating:

There's only one signing authority, and they only sign PE binaries.

Which made Linus to explode (quite rightly). Linus said what most free software user feel and wanted to say from the very beginning but neither had the strength or conviction, that Linus has:

Guys, this is not a dick-sucking contest. If you want to parse PE binaries, go right ahead.

If Red Hat wants to deep-throat Microsoft, that's *your* issue.  That has nothing what-so-ever to do with the kernel I maintain. It's trivial for you guys to have a signing machine that parses the PE binary, verifies the signatures, and signs the resulting keys with your own key. You already wrote the code, for chissake, it's in that f*cking pull request.

Why should *I* care? Why should the kernel care about some idiotic "we only sign PE binaries" stupidity? We support X.509, which is the standard for signing.

Do this in user land on a trusted machine. There is zero excuse for doing it in the kernel.

Garrett argued:

Vendors want to ship keys that have been signed by a trusted party. Right now the only one that fits the bill is Microsoft, because apparently the only thing vendors love more than shitty firmware is following Microsoft specs.

Is Microsoft really a trusted party, with more and more vendors jumping the ship and switching to Android? At this time when Microsoft is becoming weak should we commit the biggest mistake and put them back in power?

Linus later said in the thread:

You continue to miss the big question:

- why should the kernel care?

- why do you bother with the MS keysigning of Linux kernel modules to begin with?

Your arguments only make sense if you accept those insane assumptions to begin with. And I don't.

Theodore Ts'o (the maintainer of ext4) supported Linus and said:

Well, this hypothetical service could also simply scan the Microsoft revocation certificates (aka CRL's), and if the service detects a PE hash that it relied upon to resign the module, it could then issue its
own CRL revoking the signature on the module.

If it is run this way, programmatically, I'll note that anyone can run this service.  It doesn't have to be Red Hat.  It could be Linux Foundation, if the LF wanted to support this whole code signing
insanity.  (Which I really think is completely overblown, and I'm going to be amused when this blows to hell all of Red Hat's investments in Systemtap, but whatever.)  Given that I think this whole thing is insane, I completely agree with Linus's attempt to keep this insanity as far away from the upstream kernel as we can.  :-/