* Florian Weimer:
- Neal Gompa:
None of this had to be this way. It is so by our own inaction, not by the action of Microsoft.
I agree. No one but Microsoft stepped up and was willing to control the key material.
I still wish we went the way of documenting how to disable Secure Boot in commonly used firmware implementations. Secure Boot does not offer any benefit to a platform designed to be as malleable as Fedora is. I tried to start that documentation, but I got the distinct impression it was unwanted.
Instead run-time disabling of Secure Boot support without reboot comes and goes, particularly in downstream kernels. Kernel modules are such an important diagnostic tool, and not everyone plans ahead and disables Secure Boot in case they need to load kernel modules later.
(“run-time disabling of kernel lockdown“ is more accurate—but of course if there's an off switch for this feature, lockdown isn't very effective in the first place.)
And for the record, my computer's UEFI firmware is so old that "Secure Boot" cannot even be enabled at all, even if I wanted to.
Meh. That means your computer was made before Microsoft started having vendors require UEFI firmware to include their keys for Windows certification (which was in 2006/2007). I'm surprised it still works. More power to you, I guess?
Last time I checked this, the Microsoft keys required for Windows certification were not those used to sign third-party binaries like the Fedora shim (the “Microsoft Corporation Third Party Marketplace Root”). You could see the difference in Hyper-V configurations, where the default Secure Boot configuration cannot boot Fedora.
Thanks, Florian