There's a set of somewhat conflicting tensions involved in dealing with Secure Boot, and as a result there's going to be a range of solutions. The tl;dr version is that I understand why the Linux Foundation solution is the way it is, I just don't think it's terribly useful.

Doing Secure Boot properly is hard. You need to secure a whole range of components at the code level, you need to keep signing keys secure and you need to figure out what your policy is for handling key compromise or revocation. I've been working on this almost full time for a year now, and it's completely unreasonable to expect small distributions to keep up with all of this. Fedora can afford to develop and maintain the entire stack, but Mint? Arch? Slackware? I don't run any of these them, but I think diversity is important and it'd be a disaster if all of these more niche distributions vanished simply because users aren't able to install them any more.

So it's important to come up with a solution that allows end users to choose which software they want to run. To Microsoft's credit, they added a requirement that it be possible to reconfigure the key database on x86 systems after the outcry that accompanied their initial announcements. But the UI for that is wildly inconsistent between vendors, and sometimes even between different ranges from the same vendor. HP's consumer laptops need keys to be stored in one format, HP's enterprise laptops in another. It's a significant barrier to entry, especially amongst users with less technical expertise.

The Linux Foundation's approach attempts to handle that, by presenting a simple UI whenever you attempt to boot. Hit y and it'll run whatever you want. But the problem here is that it intrinsically classes Linux as a second-class citizen. Linux becomes the OS that can't reboot itself. It's the OS that pops up an ugly text entry box every time you turn your computer on. It's the OS that asks you if you're sure you want to run potentially insecure code. 10 years of progress in making Linux accessible to users, gone.

Suse came up with a more elegant approach, and we've been building on that in Fedora. The current version of Shim (so called because it wedges itself into Microsoft's trust model and bridges it into a different trust model) has bootloader-level UI that permits the user to enrol a key or a bootloader hash. If the second-stage bootloader is signed by a key it trusts, it'll simply boot that. If it's not, it'll fall back to a 10-second timeout that lets the user drop to a menu and modify their key database. If the distribution ships a signing key, they can enrol the public key. If not, they can enrol a hash of the bootloader. Afterwards, the system will boot. Post-install, it'll still boot. No dialog. No sitting there forever waiting for user interaction. One single extra step in the install process, and it's completely consistent no matter what hardware you're running on.

I think this is a wildly better solution. Big distributions with the ability to support industry expectations around secure boot can ship something that installs without any additional user interaction. Smaller distributions or end-users who want to use their own modified bootloader or kernel can enrol their key in a single step and not worry about it in future. It's not quite as easy as "press y", but it's something you do once and then your computer Just Works.

It's unfortunate that the Linux Foundation ended up taking this approach, because it's going to be perceived as the official Linux response despite it being completely different to what every Linux distribution working on this problem has implemented. Now we have to deal with a perception that Linux will only work with Secure Boot as long as you never reboot, which couldn't be further from the truth.