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://archive.is/dPFuq
SHA1 Fingerprint: 46:de:f6:3b:5c:e6:1c:f8:ba:0d:e2:e6:63:9c:10:19:d0:ed:14:f3
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
61:08:d3:c4:00:00:00:00:00:04
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
Validity
Not Before: Jun 27 21:22:45 2011 GMT
Not After : Jun 27 21:32:45 2026 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011 mokutil --sb-stateglad 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.
I (soft?)bricked a mainboard and it doesn't want to boot anymore after I removed the MS keys. The worst part is, that it has a dualBIOS and no active switch to change between them, only their own "I'll change when I see issues"... well you can guess how well that worked out (and I am not able to get it to clear CMOS for some reason).
The threat model secure boot was actually designed to protect against is not someone else booting a different OS in your hardware; the real threat model it protects against is malware loading before the OS can start the antivirus. With UEFI, malware could in theory run even when you boot from your OS install media, making it much harder to detect and remove. That's the reason installing your own secure boot key requires a one-time confirmation through a physical input device (which malware can't fake).
Unfortunately, protecting against that threat model (persistent malware loading before the OS) created another threat model, which IMO is a bigger worry: that you could one day be forbidden from running your own OS in your own devices. AFAIK, there have already been a few devices where secure boot cannot be disabled, your own secure boot keys cannot be enrolled, and the "third party" (aka "non-Microsoft") key is not available.
mokutil --db --short
I didn't even realize this could be a problem despite the next paragraph implying it's very well known.
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.
I know it is not recommended but the options to have my own keys seemed a bit of a hack than a solution.
Not all devices support it, so choose wisely.
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!
By trusting another chain of trust and firmware binary blobs involved in booting your PC.
Secure boot exists only as one of the puzzle pieces for remote attestation for MS and trusted OEMs, nothing to do with your security.
99% of secure boot discussions are drowned out by people who don't have a clue what they're talking about, yet are spittingly, furiously mad.
They've also had over a year to prepare for this so if Linux distros are only telling you now, that's on them.
The issue seems to be that Microsoft will refuse to sign anything new with the expiring certificate (which is correct behaviour), so any UEFI firmware that hasn't got the new certificate will refuse newly signed bootloaders.
I don't see anything wrong with this scenario, it's on distros to properly make sure they're distributing secure boot certificate updates.
Edit: Apparently RHEL will even refuse to install a 2023 signed shim if the firmware lacks the certificate for it.
Why is that? RHEL own blog post described that RHEL is distributing dual signed shim by both 2011 and 2023 certificates, so that it works either way, only 2011 present or only 2023.
Well yea - as someone who has 0 understanding of why we need it, and only ever get greatly frustrated by it, I am pretty mad that people feel entitled to call my distro managers "that's on them"
https://mjg59.dreamwidth.org/72892.html (Secure boot certificate rollover is real but probably won't hurt you)
https://wiki.debian.org/SecureBoot/CAChanges#OMG.21.21.21_Wi...
Does this means that updating my system kernel would fail or even break 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.
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.
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.
So what? I'm still preventing a random person from tampering with my bootloader?
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.)
Similarly, I've been using zopfli (gzip/unzip compatible) for png compression after quantization for db storage from 2-color (B/W) scans as it's directly compatible to the browser but winds up about 1/6 the original sized tiff. Not the best compression, had a discussion for a better compression, but required a wasm renderer to decompress as it isn't in the browser box.