Having read through the entire thread instead of just the expletives, in my opinion it's a rare case of Linux and Greg being totally wrongheaded on the issue.
The problem crops up because redhat submitted a pull request to enhance the existing in kernel live inclusion of additional trusted x.509 certificates. Note that this is 100% upstream and live. The pull was to add the ability to extract these x.509 certificates from UEFI PE binaries, as this is the only format they are available in from the only CA UEFI secure boot computers are guaranteed to trust - Microsoft's CA.
Linus decided he didn't like it because he didn't like the idea of extracting a certificate instead of having it alone. Understandable, probably, except that leaves you in a situation where a secure kernel that was executed due to a microsoft CA chain of trust now can't make use of that CA's code signing services to decide if it wants to run a module solely because linus doesn't approve of parsing the file format that contains the key.
The biggest place this comes up is binary only graphics drivers from ati and nvidia - without changes os's like fedora are going to refuse to run them because they're unsigned, which is unfortunate considering how uneven some of the open source 3d drivers are and the heavy reliance on 3d in all modern desktops environments.
Meanwhile microsoft is perfectly willing to sign these drivers and has an existing substantial CA operation. Both ati and nvidia submit their windows drivers for signing to this CA all the time, so it'd be almost no extra effort for them to get their linux shims signed as well.
But because linus thinks parsing a PE for a signed module key is asinine, he goes on to provide a series of rather off the cuff alternatives:
a) Every distro should parse the PEs and add every key of every 3rd part module they wish to allow to run and embed these in their signed kernels, issuing a new kernel every time a driver revs.
b) ok, maybe that's not ideal. how about every distro that wants to allow binary drivers to run builds their own CA infrastructure, verification and qualification team and revocation infrastructure. So that's a team at cannonical, redhat, novell, mint, oracle, ibm, etc. etc.
c) ok, maybe full ca teams are a bit burdensome. How about all you distro guys just blind sign the binary drivers with your own signing key - worrying that MS might revoke your key because you blind signed an exploit is pointless fearmongering.
d) ok, you're right this is harder than i thought. let's just collectively decide that users with secure boot enabled will be prevented from running any module not shipped by the os vendor. Aka fuck off unless you're using intel video.
e) alright, maybe that's a little severe. Instead let's just punt entirely - even though we're going through the trouble of a chain of trust from firmware to boot loader to kernel to most modules, let's allow any unsigned binary module to be loaded by default.
f) ok, i guess that kind of defeats the purpose. None of this is good security anyway - what we should be requiring is any user that wants to use secure boot should generate their own signing keys, add them to the firmware and then parse and sign everything they trust, repeating the process every time they update while of course protecting the signing key from attackers.
I think that about covers it. Linus is really smart, but sometimes he makes a snap decision and then will perform whatever mental gymnastics are necessary to defend it to the death. And most of his inner circle will publicly go along with it because of the real chance he'll pay you back by randomly torpedoing something of yours sometime in the future.
Linux's signed code infrastructure is currently the worst in the industry and Matthew and Redhat have provided the bulk of the improvements that everyone is using. It's going to provide real user benefit, even if the users are paralyzed by FUD. Getting in the way of the process or trying to punt it out of mainline and onto everyone who ships a distro isn't going to help anyone.