this post was submitted on 22 Jul 2025
192 points (97.5% liked)
Linux
8740 readers
365 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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?
I personally dont think MS did it out of maliciousness, more indifference. They wanted the security benefits, and didn't care what it cost others. But we'll likely never know what their true intent was.
~~I dont know how the bazzite script does it, but any tool that can be executed from userspace that could add keys could just as easily be abused by malware to add their own signing keys, which completely defeats the purpose.~~ Edit: see princessnorah's comments below for more details, but it is a lot more hands on, which prevents malware abusing it.
In an ideal world, Redhat, Canonical, Suse etc could have gotten their verification keys built into every motherboard, but that still cuts out the Arch/Gentoo/flavour-of-the-month crowd. And also increases the risk that a signing key gets leaked and abused by malware.
Its just not an easy problem to solve.
So how do we fit AI into this scheme 🤔