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).

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.

    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

On my Fedora machine I was able to run

    mokutil --db --short 

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'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.

> 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.

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"

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...

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.

[1] https://www.youtube.com/watch?v=_Ua-d9OeUOg&t=253

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.

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.

> What is the convincing reason that MicroSlop is the trusted party to sign the shim with their (presumably NSA-blessed key)?

For OEMs, presumably the stranglehold they have on them via Windows. For users, not much, but none of the ones making these decisions really care about that.

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.

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.

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 for your own security, duh ;)

> presumably NSA-blessed

You have your answer

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!

I don’t know why we ended up trusting microslop. Red Hat implemented it for the sake of convenience causing all these issue.