Fuck no. He's fucking done enough.
I say that as a long-time Linux user, a developer and a security researcher. He's set us back a decade with his metastatic cancer.
This is a most excellent place for technology news and articles.
Fuck no. He's fucking done enough.
I say that as a long-time Linux user, a developer and a security researcher. He's set us back a decade with his metastatic cancer.
Explain like I'm five?
Id love to be as angry as you are.
Why not just expand on Libreboot instead?
Im fine with anything that is gpl as long as its through the whole stack starting at hardware.
An alternative to secureboot that isn't secureboot but behaves like it. Wonderful 🙄
Another Poettering "masterpiece" ready to be gobbled up by his fanbase who will flock towards the new and shiny toy that forgoes the things that actually work fine or aren't solving an actual problem with 99% of whatever it's used by. Great 🙄 🙄 🙄
EDIT:
No doubt this will be his opportunity to force everyone off grub and use systemd as the bootloader across major distros. As valid as it may be to succeed grub, surely systemd is not the answer to this.
Can't wait to not be able to VR game with my Nvidia GPU on Linux cuz they can't be arsed to properly sign their damn proprietary drivers.
Nvidia can't meaningfully sign their Linux drivers. A distribution can, in theory, include Nvidia drivers in their build and sign it, but the logistics of out of tree drivers is just impossible.
Redhat toys with the concept of a whitelisted ABI for some limited range of kernels, but I've never seen a driver actually roll with that.
Basically Linux would need to embrace some form of ABI, and there's been zero interest in doing so.
The option of having a full auth trust chain would be nice for some security applications, but the implication that it could be made compulsory is terrifying.
It'll start as an option and slide into compulsory later. It's the Systemd way.
You can already secure boot if you want. But like always, you gotta set it up yourself in a complicated manner :D
It’s Linux. In what world do you imagine there wouldn’t be 87 forks that went in a different direction.
Linux cannot be controlled, at least as it stands today.
When Linux disappears I have some fears. But jerk as he may be, he’s also incredibly effective at keeping it open.
In what world do you imagine there wouldn’t be 87 forks that went in a different direction.
In every world. Linux is not just the codebase, it's all the developer work going into it daily. Hundreds of forks and downstreams can pick whichever direction they want, most of that work will still be directed one way.
But this proposal for a full auto-chain isn’t a proposal by Linus and many thousands contributors. It’s the proposal of a commercial entity that doesn’t control Linux in any way.
Yes, this commercial entity founded by people who have a literal track record of doing exactly that

Volunteer adoption of a system found to be better by distro maintainers is not the same as forced adoption of a system distro maintainers don’t find to be better.
"Found to be better" because of commercial resources and support pouring in and outcompeting grassroots alternatives to gain market share. Do you share the same lukewarm acceptance for what chromium is doing for web browsers?
I’m not sure what we’re arguing about now, but I’m convinced it’s not the original point I was trying to make. I think both of our lives are too short to carry this one. Have a good evening.
I don't trust Microsoft, why should I start trusting IBM/Canonical or Poettering now.
If the possibility is there they will happily lock you out of your own hardware.
I've made other comments before about how we used to cheer for Google back in the 00's because they were the upstart that took on the entrenched competitors (Microsoft primarily). Look what Google has become today - the very thing we hoped they would destroy, and they are so much worse about it.
Red Hat/IBM ultimately owned by the same people as Google: shareholders. Nothing will ever stand in the way of their greed. If this technology is allowed to exist, there's no reason to think that it too will be used against our interests.
Who decides what SecureBoot considers trustworthy? If SecureBoot is controlled by someone else then it can be used against the user. The aversion to SecureBoot is justified.
Secureboot uses certificates to verify integrity. The user is able to install new certificates. So I'd say it is the user? I'm not an expert though and their may be hardware out there that doesn't allow new certificates.
AFAIK, the allowing the user to install and remove certificates is a x86_64 thing only, arm will happilly fuck you over, x86_64 UEFI implementations ARE REQUIRED TO add that feature to be spec compliant, this was a intentional decision by Intel and AMD to keep x86_64 open to new OS and not locked down to Windows which could one day be a sinking ship, so that x86_64 would not be at the mercy of Microsoft's success and attachment to the platform
I have seen some platforms locked to Microsoft first party keys only. They boiled the frog by starting with it being optional, able to enroll your own keys, and Microsoft signing third party bootloaders, but now there exists a Microsoft-only certificate regime that at least some vendors have selected, or at least made a selectable option. The pitch being that Windows shops that don't trust their users can be assured they aren't deviating from the blessed windows os their IT trusts.
The user is able to install new certificates.
That's true today, but there's no guarantee it will be true in the future. Google is already pushing for all software running on Android to be cryptographically verified and they (Google) are the only ones that control the signing keys. This means that they intend to kill off F-droid and all other software delivered outside the Google store.
If Google is able to pull it off on Android, everyone else will try to do it on desktop OSes too - Linux included.
That’s true today, but there’s no guarantee it will be true in the future.
It's in the specification.
The platform key establishes a trust relationship between the platform owner and the platform firmware. The platform owner enrolls the public half of the key (PKpub) into the platform firmware. The platform owner can later use the private half of the key (PKpriv) to change platform ownership or to enroll a Key Exchange Key. See “Enrolling The Platform Key” and “Clearing The Platform Key” for more information.
The platform owner clears the public half of the Platform Key (PKpub) by deleting the Platform Key variable using UEFI Runtime Service SetVariable(). The data buffer submitted to the SetVariable() must be signed with the current PKpriv - see Variable Services for details. The name and GUID of the Platform Key variable are specified in Globally Defined Variables. The platform key may also be cleared using a secure platform-specific method. When the platform key is cleared, the global variable SetupMode must also be updated to 1.
It's a matter of clearing the platform key & enrolling your own platform key. I've done this before.
Typically, computers with Secure Boot let us clear the platform key from the boot menu. (You can choose to purchase only those that do.) Some computer vendors let the customer provide public keys to ship preloaded.
Secure Boot has always been for enabling the owner to enforce integrity of the boot process through cryptographic signatures. Linus Torvalds thought the feature makes sense.
Linus: I actually think secure boot makes a lot of sense. I think we should sign our modules. I think we should use the technology to do cryptographic signatures to add security; and at the same time inside the open source community this is so unpopular that people haven’t really worked on it.
It’s true that secure boot can be used for horribly, horribly bad things but using that as an argument against its existence at all is I think a bit naive and not necessarily right. Because if you do things right then it’s a really good thing. I would like my own machine to have the option to not boot any kernel, or boot loader, that is not signed by this signature.
That's right. The user (or administrator if it's a work machine) installs or removes acceptable certificates into firmware database. Typically a device you buy in the past 15 years or so comes with Microsoft certificates preinstalled, but it doesn't have to stay like that.