The continued Linux desktop solely relies on antivirus vendors writing crappy insecure software. So we'll be fine forever.
This conspiracy was never true and never happened. First off, note that the first version of the thing in the article you’re commenting on relied on a Fedora shim loader which Microsoft signed. Second off, note that almost all modern motherboards let you enroll your own UEFI keys and do not rely on exclusively the Microsoft keys.
The only place this is was becoming an issue for Linux was early Secure Boot implementations where the vendor was too lazy to allow key enrollment, and that era has generally passed.
Further, many distributions are already compatible with Secure Boot and work out of the box. Whether or not giving Microsoft the UEFI root of trust was a good idea is questionable, but what they DO have is a long, established history of supporting Linux secure boot. They sign a UEFI shim that allows distributions to sign their kernels with their own, distribution-controlled keys in a way that just works on 99% of PCs.
Is this really true, in 2019 when this was written or today? I haven’t seen a motherboard that didn’t let me enroll my own keys in a really long time. Laptops are a different story but even there, it’s been awhile.
> Microsoft forbid to sign software licensed under GPLv3 because of tivoization restriction license rule
Ah yes, GPLv3 is now Microsoft’s fault?
From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microsoft, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD...
Crucially the end user should then be ASKED which to enable. None should be enrolled out of the box. They might also be enabled only for specific things. E.G. HW vendor could be enabled only for new system firmware signatures (load using the existing software) rather than generic UEFI boot targets. The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures.
It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. This would be a great place to stash things like UEFI drivers for accessing additional types of hardware drivers, OS boot bits + small related files, etc. I would have said 1GB of storage would be more than sufficient for this - however Microsoft has proven that assumption incorrect. Still it'd be nice to have a standard place and a feature that says the system ships with this much reliable secondary storage included (or maybe 1-2 micro-SD card slots, etc).
ronsor•40m ago
The biggest weakness of secure boot was always third-party vendors shipping "insecure" bootloaders. It's a lot of work to verify signatures for every bit of data that gets loaded, especially on the PC platform.