Linux and Secure Boot certificate expiration (2025)

Microsoft is the trusted party because they convinced hardware manufacturers to install their keys by default; that's it. A lot of commercial/industrial/pre-branded OEM hardware comes without Microsoft's keys, they're only there for the Windows Logo.

> Why is there no charitable equivalent like a small/mini LetsEncrypt foundation for the PKI aspect of Secure Boot?

This would be pointless and erode the security of the system. Users who care can already remove Microsoft's root keys and enroll their own. There's a small corner case with UEFI Extensions / device firmware, but in this case a lightweight "sign everything" foundation would only serve to erode the security of the system. The problem space is completely orthogonal to website SSL and by and large simply good and not bad when properly configured.

> I also do not see a convincing reason it meaningfully improves security posture.

Secure boot paired with secure boot-sealed disk encryption massively reduces attack surface; with only Secure Boot-sealed keys (ie, BitLocker default), it reduces attack surface for the data on your disk to "post-boot authentication bypass or RCE" from "literally anyone or any piece of software who touches your computer or a disk that came out of it, ever." With keys sealed by Secure Boot and sealed or even just stretched by another mechanism (password, PIN, etc.), it reduces attack surface to "machine unlocked."

> MicroSlop is the trusted party to sign the shim with their (presumably NSA-blessed key)

I've been on Hacker News for an extremely long time and respect the community wish to avoid meta-discourse in general, but this kind of rubbish discourse with weird slurs and unfounded conspiracy theories is getting horrendous lately; I wish this site could more collectively move towards a productive curiosity rather than evidence-free statements based on arbitrary prejudice.

I disagree that there is no need for secure boot for Linux?

Secure boot prevents tampering of your kernel and/or bootloader, nothing about Linux prevents this from being possible.

You might argue that you don't care about this, but some people such as myself do!

Because they were the only party competent enough to run a PKI (which is 95% policy) while Linux distros still can't agree on a single boot loader.

shim didn't exist at first. Linux was planning to go without until Red Hat's hand was forced likely because their paying customers demanded it.

My very recent story with libvirt and secureboot resulted in blanket disabling of secureboot as part of the preparation for creation of VMs.

The reason: the VM refuses to boot when provided with an ISO (via virtual CDROM) with a meaningless error (permission denied: go figure out what permission and why was it denied and by whom).

Secureboot is meaningless / useless for most people running VMs, be it on own or rented hardware. It takes some pain and extra work to get it to work sometimes, and a huge amount of work to get it to work always. I doubt anyone was dedicated enough to get it to work always. So, I believe you are right. This is extremely unlikely to be a problem for anyone running Linux VMs, and the more VMs they need to run, the less likely it is a problem.

I've honestly always kept secure boot off on my machines (which also use Arch). I don't really feel like the level of threat from someone (or me, by accident) booting an image I don't want them to on my hardware is particularly worth the hassle it brings; nobody else should ever be using my machines in the first place, and if they are, I'm going to have larger issues than what OS they decide to try to boot.