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.
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. 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.
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.
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.
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.
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.
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'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'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.
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.
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.
[1] - https://nochan.net/b/Internet-Crap/20260621-Update-Secure-Bo...
[2] - https://archive.is/ml3jv
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. 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.
[1] - https://caniuse.com/brotli
Found this on one machine. Key expires in 5 days. System runs Linux only and has never booted Windows, ever. Secure boot may be off.
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.
Thanks.
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.)
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.
Discussed at the time (of the article):
Linux and Secure Boot certificate expiration - https://news.ycombinator.com/item?id=44601045 - July 2025 (265 comments)
Last time I installed Arch, I put Secure Boot in setup mode and enrolled by own keys. The idea of using someone else's keys seems absurd.
I saw 2-3 flavors of this news. None of them include a basic “how do I check if I need to do anything” guide that a linux newbie can do.
On my Fedora machine I was able to run
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.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.
Red hat always creates problem in 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.
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'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.
It's for your own security, duh ;)
> presumably NSA-blessed
You have your answer
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.
> The KEK updates are going out at ~98% success, and db update is ~99% success
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.
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.
I don’t know why we ended up trusting microslop. Red Hat implemented it for the sake of convenience causing all these issue.