They left out the steps to update it. I made a rough attempt at a document for this. [1] Please let me know if I missed a validation step. I have done this on six machines but they were all Linux. Not tested on BSD.
Archive [2] in the event I was too aggressive in blocking bots.
[Edit] I should also include this [3] thread for completeness sake. Some people people were playing with a shim work around but it looks like a lot of unnecessary complexity and fragility to me.
FYI your server returns Brotli encoded content, even if the request has only Accept-Encoding: gzip, deflate, zstd - making it unreadable in for me (Firefox on Fedora).
I actually did that on purpose since all browsers support brotli I risked the possibility someone might have disabled it with an add-on. I wanted to see how many bots that would break. It may not be the most logical process but I just use CanIUse [1] to see what supports Brotli. I ignore the Opera Mini block as they seem to support almost nothing.
Nothing wrong with that. I think people should be able to disable anything they want. I doubt any commercial sites will do what I am doing. I use that little blog to test all manor of unorthodox things. That's why I listed the archive mirror, just in case.
I had to vouch your comment, not sure what happened there. Something in your technical output must have triggered HN. One can use mokutil to see if Secure Boot is enabled after installing it. I assume the OEM installation or update of the BIOS must have included that cert but I am just guessing.
My ASUS laptop had it enabled. I had to disable it as there just wasn't enough non volital memory to hold all the updates even after remove several EFI entries and resetting the BIOS. All my mini-PC's updated fine however. My Linux Protectli routers already had it disabled thankfully. They use Coreboot, unsure if that was a factor.
To check my secure boot keys. As long as there's 2023 Microsoft keys you should be fine. Otherwise, my understanding is that you just need to update your firmware, but please somebody correct me if I'm wrong.
I'm surprised more people aren't freaking out about this. It seems likely a whole lot of Linux machines are going to fail to reboot in the next few months. The problem affects VMs too. I was grateful Proxmox put a little warning in its hypervisor GUI with a button to press to fix the BIOS of its VMs.
Secure Boot has been deeply broken for years, not providing meaningful security on most consumer machines.
I don't have any numbers to prove it, but I'd say the reason Linux users aren't freaking out is because the vast majority of them would've have disabled Secure Boot. In fact, many guides and videos from popular Youtubers[1] explicitly state to disable Secure Boot.
As for VMs, whilst the problem indeed affects them too, the reality is that most hypervisors - even commercial ones - don't actually enable Secure Boot by default, you'd have to go really out of your way to enable it for a VM.
Why has it been broken? I’m running secure boot on all my machines with my own certs. It works fine.
Whatever ms and hp / Lenovo do with their certs doesn’t affect me, since I only have my certs installed. Except on a single machine whose purpose is running windows, but it’s not on the critical path for my job.
What is the convincing reason that MicroSlop is the trusted party to sign the shim with their (presumably NSA-blessed key)? Why is there no charitable equivalent like a small/mini LetsEncrypt foundation for the PKI aspect of Secure Boot? I also do not see a convincing reason it meaningfully improves security posture.
In 2012, Windows 8 stopped booting on computers without UEFI secure boot. Hardware companies weren’t enthusiastic, but they couldn’t ignore Microsoft’s demand. Microsoft published the spec for how Windows 8 would handle secure boot, and that included the crypto key that will be expiring in September. Microsoft’s spec did actually have provisions for non-Microsoft operating systems.
Linux developers didn’t all agree about whether Linux needed to do anything about Microsoft’s plan, but ultimately a Red Hat programmer convinced enough people that it would be easier to follow Microsoft’s spec than to tell new users to “turn off secure boot” if they wanted to run Linux ( https://mjg59.dreamwidth.org/12368.html ). This wasn’t a popular decision, and it hasn’t become any more popular over time, but it has worked.
No. I was there in 2012, Redhat's solution was the only solution which would have properly worked. Eventually, the infrastructure developed for measured boot due to these measures allowed Linux to use TPM in it's proper usage, and allowed sedutils and similar applications to be supported on linux.
You can load your own Secure Boot keys and sign your bootloader yourself; as for why the Microsoft ones are preloaded, probably because they're the only entity that interacts with all of these OEMs and had enough leverage over them to force Secure Boot adoption in the first place.
It should be just "hey, do you trust this install media" -> "yes" -> boot key is automatically added at this step.
Instead the whole ecosystem is at microsoft whim
If it becomes this easy then Secure Boot just becomes Vista-era UAC. Sometimes making the security bypass an intentional act that requires some knowledge is a good thing. Most PC users, were their bootloader compromised and they saw such a screen on startup, would instantly press yes and forget about it within 5 minutes.
Not to say that having Microsoft as the custodian of the keys preloaded on all PCs is the optimal solution, but I don't think a token yes/no to add any random key on boot is a good idea either.
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.
It's not exactly new for Microsoft to slide themselves in somewhere and become the "standard" before anyone has really thought about how terrible their products are.
I mean, NSA-blessed or not, the way this happened was not some hidden conspiracy. It was in the open. The reason it happened is all of these machines are basically made to run Windows, so they need to have Microsoft keys. Microsoft was pushing for Secure Boot, for security and "trusted computing" (evil or good, depending on your PoV,) and open source complained that this is a way to lock in users to Windows, so the compromise choice was to have them sign a GRUB shim so that Linux could just as easily be run without enrolling your own keys.
It needs to be said, this is what you get by "trusting" Microsoft.
There really is no need for secure boot in Linux. The only reason to have it is if you dual boot because M/S says so. If using Linux by itself, just disable secure boot and have done with it.
Archive [2] in the event I was too aggressive in blocking bots.
[Edit] I should also include this [3] thread for completeness sake. Some people people were playing with a shim work around but it looks like a lot of unnecessary complexity and fragility to me.
[1] - https://nochan.net/b/Internet-Crap/20260621-Update-Secure-Bo...
[2] - https://archive.is/ml3jv
[3] - https://www.reddit.com/r/archlinux/comments/1pvw6td/grub_shi...
[1] - https://caniuse.com/brotli
Just checked. Secure Boot is not enabled on any of my machines, which are Linux-only. Whew!
(I wonder if any of the ASUS subnotebooks I bought off eBay for minor embedded stuff have this problem. Have to power them up.)
Linux and Secure Boot certificate expiration - https://news.ycombinator.com/item?id=44601045 - July 2025 (265 comments)
Secure Boot has been deeply broken for years, not providing meaningful security on most consumer machines.
As for VMs, whilst the problem indeed affects them too, the reality is that most hypervisors - even commercial ones - don't actually enable Secure Boot by default, you'd have to go really out of your way to enable it for a VM.
[1] https://www.youtube.com/watch?v=_Ua-d9OeUOg&t=253
Whatever ms and hp / Lenovo do with their certs doesn’t affect me, since I only have my certs installed. Except on a single machine whose purpose is running windows, but it’s not on the critical path for my job.
glad to see the opt in fwupd analytics being so useful for something like this
Not envious of the running around contacting vendors they must of been doing on such short order.
Linux developers didn’t all agree about whether Linux needed to do anything about Microsoft’s plan, but ultimately a Red Hat programmer convinced enough people that it would be easier to follow Microsoft’s spec than to tell new users to “turn off secure boot” if they wanted to run Linux ( https://mjg59.dreamwidth.org/12368.html ). This wasn’t a popular decision, and it hasn’t become any more popular over time, but it has worked.
Not to say that having Microsoft as the custodian of the keys preloaded on all PCs is the optimal solution, but I don't think a token yes/no to add any random key on boot is a good idea either.
> 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.
You have your answer
There really is no need for secure boot in Linux. The only reason to have it is if you dual boot because M/S says so. If using Linux by itself, just disable secure boot and have done with it.
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!