Linux users are about to face another major Microsoft Secure Boot issue

Secure boot can't fail due to expired certificates if it's already disabled...

So, is there any consensus if secure boot is even needed at all? I've read so many different opinions about this the past few days and have no idea.
- As almost always the answer is "it depends".
  From a security perspective you want to make sure that what your system boots is trusted and not tampered with by a third party. If your threat model includes people with physical access or malicious software (root kits) manipulating your operating system, then secure boot can help mitigating if you set it up correctly.
  If that's none of your concern, then you probably shouldn't bother with it.
  
  As almost always the answer is “it depends”.
  From a security perspective you want to make sure that what your system boots is trusted and not tampered with by a third party. If your threat model includes people with physical access or malicious software (root kits) manipulating your operating system, then secure boot can help mitigating if you set it up correctly.
  If that’s none of your concern, then you probably shouldn’t bother with it.
  It's such a silly system. Could have just had it in a way that automatically trusts only whatever system(s) is/are installed while the BIOS is unlocked so any user benefits from secure boot as soon as they set a BIOS password.
- It is really important for devices like laptops. A good secure boot implementation will protect against evil maid attacks and prevent people from easily modifying the kernel, initramfs and other critical components while Tue device is powered off.
- imo if you dont have disk encryption then thats worse than not having secure boot.
  secure boot mainly protects your computer from having certain hardware components and the bios tampered with right?
- For all of my personal machines secure boot is disabled.
  The main benefit is enabling signature checks on every piece of code that runs to start your machine. This is a good idea to prevent direct modification of the binaries involved. This will work as far up the chain as software supports, even to userland code although I don't know of any Linux distros do that.
  However, if you occasionally rebuild any of that software and can sign it yourself secure boot just moves the attack surface from the binaries into the build process. Any modifications made to the kernel, bootloader, or firmware before signing are included as trusted code and are vulnerable to malicious modification.
  Since I don't / can't verify every piece of code on my system, and rebuild Linux occasionally, and people have demonstrated secure boot bypass flaws, I prefer to disable secure boot entirely for convenience. Also, in a roundabout way this increases the security of my system because I won't get locked out for misconfiguring an update.

All the more reason to buy your computers from companies that support Linux in the first place - like Slimbook and System 76.
- And Tuxedo in Germany - just got my InfinityBook pro 14 and it’s been great.
- I know System76 doesn't support Secure boot. I'm not sure about Slimbook.
  I wish they would ship a open UEFI implementation with customizable Secure boot keys.
- Not sure, I have a computer from a Linux builder but it still has UEFI. I am trying to figure out where I stand on this.

On Bazzite there is a built-in ujust script:
enroll-secure-boot-key # Enroll Nvidia driver & KMOD signing key for secure boot - Enter password "universalblue" if prompted
But I don't really understand how Secure Boot works so far, so I wonder if using it fixes the issue.
- That should exactly fix the problem.
  The real issue is that by default, if secure boot is enabled, you won't be able to boot up into bazzite or whatever in order to run that command.
  So the user experience will be worse now, because instead of just installing and running, Linux users have to disable secure boot, boot and install their distro, run that enroll command, and then reenable secureboot. And lots of people are going to give up at step 1, and leave secureboot off.
  
  Microsoft is counting on that
  EDIT: could they just make this part of the install process? Could they make it like a thing that runs on first boot, if you can only do it from within the kernel/boot loader that is to be authorized?

Secure boot security used as ransomware to ensure Windows purchases.

Nah, don't use it. Secure boot is tainted by Microsoft 🤮

Another thing to watch out for is fake third-party utilities that will claim they will fix this problem. Unless directly provided from an official Distro itself and is verified, be careful what you download and install.
This is a golden opportunity for malicious actors to get bad code into systems.

My bios doesn't need to know what year it is
- For you and me, that's fine, but for little johnny first time, it's adding friction and new points of failure that push the whole idea further away from their comfort zone.
  It could be argued that Microsoft knows this and is deliberately weaponizing peoples insecurities to keep them in line.
  Also, "Been available since 2023" means Microsoft gave distros 2-3 years to implement the new signing keys. Yet they'll give themselves decades between signing and updating their own root certificates.
  Example: on my work machine, "Microsoft RSA Root Certificate Authority 2017" is valid from 2019 to 2042. It's valid for 25 years, but it took Microsoft 2 whole years to deploy the certificate within it's own structure, specifically to get all the relevant sign-offs needed to issue the cert.

Has anyone here generated their own keys? I'd looked into it before and it didn't seem too complicated (but never tried).

In case it helps: I just got an update for "Microsoft UEFI CA" on my computer running Fedora KDE 42, from "Firmware Updates (lvfs)". Check your software centre.

How would we know if this will affect us? I have been running Linux distros for 20 years and didn't know Microsoft was involved at any level in firmware.
- It might. It depends on a lot of stuff.
  Microsoft was heavily involved in the making of uefi and secure boot but had heavy resistance from canonical as the early drafts of secure boot would not allow os' to add signing keys to the tpm so a machine would only be able to boot windows.
  Thankfully canonical won that debate :')
  
  I definitely have UEFI, not sure about secure boot.
  
  Can I trouble you to elaborate?
- As a rule of thumb, if you run any PC hardware at all, then Microsoft is involved in it.
  
  Maybe, but what about units supplied by a Linux builder? My last computer was a windows machine I installed Linux on, but that was before this I think. It shipped with windows 7.

Nit knowing secure boot all that well, why isn't there an option in BIOS (I know, I know) to upload the new key manually? That really cannot be that hard...