61–70 of 70 posts
How do desktop Linux distros avoid attackers from rolling back the operating system to a vulnerable, but signed version?
How do desktop Linux distros avoid attackers from rolling back the operating system to a vulnerable, but signed version?
This is not an issue specific to Linux, Windows installations can be downgraded as well. As for the mechanism, UEFI devices, alongside key updates, also get revocation list updates.
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 (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).
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 lik…
[1] - https://archive.is/dPFuq
Earlier quoted context omitted.
Existing systems are going to continue to boot. The expiry date is enforced for signing new binaries, not for deciding whether an already signed binary is allowed to boot (barring buggy firmware). 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...
> he expiry date is enforced for signing new binaries Does this means that updating my system kernel would fail or even break boot?
Earlier quoted context omitted.
Ah, fair enough. Well Firefox should support Brotli by default, so it's probably something going on on my machine.
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.
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.
Not all devices support it, so choose wisely.
Earlier quoted context omitted.
Existing systems are going to continue to boot. The expiry date is enforced for signing new binaries, not for deciding whether an already signed binary is allowed to boot (barring buggy firmware). 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...
> he expiry date is enforced for signing new binaries Does this means that updating my system kernel would fail or even break boot?
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.
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.