Linus Torvalds: I will not change Linux to “deep-throat Microsoft” "This is not a d**k-sucking contest," says Linux's benevolent overlord.

AT LEAST somebody got the BALLS  to say WHAT they are REALLY thinking ! .....alright you can put yer helmets & mittens back on :o

Linus Torvalds: I will not change Linux to “deep-throat Microsoft”

"This is not a d**k-sucking contest," says Linux's benevolent overlord.

by Jon Brodkin - Feb 26 2013 http://arstechnica.com/information-technology/2013/02/linus-torvalds-i-will-not-change-linux-to-deep-throat-microsoft/

Linus Torvalds will never get a job in HR.

aaltouniversityace

The Linux kernel development process may welcome all those who love open source software and have the right coding chops, but one man remains the ultimate authority on what does and doesn't go into Linux—and he isn't afraid to let everyone know it.
The rants of Linux creator Linus Torvalds often become public through the Linux Kernel Mailing List archive. That's the open source way, and it gives us a glimpse into the thinking of the people behind one of the world's most widely used technologies.
The latest example comes from an argument between Torvalds and other Linux developers over whether the Linux kernel should include code that makes it easier to boot Linux on Windows PCs. This goes back to Microsoft requiring that PCs designed to run Windows 8 use UEFI firmware with the Secure Boot feature enabled. This has complicated the process of booting Linux on PCs that shipped with Windows 8, but it hasn't prevented people from doing so. There are workarounds, but some people are looking for a solution in the Linux kernel itself.
Last Thursday, Red Hat developer David Howells posed a request to Torvalds, which reads in part:

Hi Linus,
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.
Now, "keyctl add" will already handle X.509 certificates that are so signed, but Microsoft's signing service will only sign runnable EFI PE binaries.
We could require that the user reboot into the BIOS, add the key, and then switch back, but under some circumstances we want to be able to do this whilst the kernel is running.
The way we have come up with to get around this is to embed an X.509 certificate containing the key in a section called ".keylist" in an EFI PE binary and then get the binary signed by Microsoft.

Warning: Graphic language ahead

Torvalds replied that the idea was "f*cking moronic." Red Hat developer Matthew Garrett noted in response that "There's only one signing authority, and they only sign PE binaries," referring to Microsoft signing Extensible Firmware Interface Portable Executable binaries.
Torvalds' response to Garrett was explicit:

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 chrissake, 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.
Linus

You might think that would end the conversation for good, but not quite. Howells pointed out problems in Torvalds' suggested approach, saying:

There's a problem with your idea.
(1) Microsoft's revocation certificates would be based on the hash of the PE binary, not the key.
(2) Re-signing would make the keys then dependent on our master key rather than directly on Microsoft's. Microsoft's revocation certificates[*] would then be useless.
(3) The only way Microsoft could then revoke the extra keys would be to revoke our *master* key.
[*] Assuming of course we add support for these.
David

Garrett noted that modifying the Linux kernel would be due to practicality more than anything. "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," he wrote.
Greg Kroah-Hartman, maintainer of the Linux kernel's stable branch and the Linux driver project, put in his two cents, noting that various Linux distributions already allow Linux/Windows dual-boot scenarios due to "a UEFI bootloader/shim that Microsoft has signed." (That shim was created by Garrett.)
"I'm not saying that they are not nice things to have, personally, I want some of these things for my own machines just to make things more secure, but again, these are 'I want to have', not 'Someone else is saying Linux MUST have,'" Kroah-Hartman said.
Howells hasn't given up. In an e-mail yesterday, he noted that "Unless we get the administrator to add a key prior to Linux installation, Linux cannot be booted on a secure UEFI machine—unless the boot loader is signed by Microsoft's key." In the thread's latest e-mail from today, he responds to one of Kroah-Hartman's arguments.
The discussions illustrate how proposing changes to the Linux kernel can be controversial. We imagine these types of discussions happen all the time at software companies, but without becoming public like they do with Linux. What do the CEOs of major software companies say behind closed doors when they hate a proposal made by one of their underlings? We don't know, but when it happens with Linux, we do.
Torvalds isn't a CEO, but the final decision will likely come down to what he wants. Torvalds is an employee of the Linux Foundation, which allows him to remain independent while working full-time on maintaining Linux.
As the Foundation notes, "Torvalds remains the ultimate authority on what new code is incorporated into the standard Linux kernel."