But a method of doing that wasn't included in the UEFI standard for obvious Microsoft reasons, so few vendors support it and those that do usually don't do it correctly, let alone in a standardised way.
Happy to be corrected if things have changed since the last time I looked at things.
Not always possible. Depends on firmware support and we all know how shitty proprietary firmware can be.
When you control the keys, SecureBoot is a good thing at least as good as encryption!
There are things that are fair to complain about, but on this, I don't see how Microsoft or anyone could have done any better to be playing nice with Linux while helping customers.
I have computers that don't have this feature.
> When you control the keys, SecureBoot is a good thing at least as good as encryption!
I agree. It's all about who owns the keys to the machine. If we do, then it's all good.
That's not a fair assessment. Linux used a whitelisted shim, which only included accepted entries in an easy-to-edit/hack EFI variable. Imagine writing your secret password on a normal VFAT partition that any OS can boot/read/change. This is the equivalent.
The proper way is to enroll the private keys with the bios, and sign the payloads yourself (or let your distribution handle that), which is way more secure and can be automatized if you select the custom secureboot.