On Wed, Apr 6, 2022 at 8:04 PM Justin Forbes jmforbes@linuxtx.org wrote:
We have not set up an infrastructure for it, but in all honesty, there is no technical reason that any 3rd party repository building and packaging the driver could not have done such a thing a couple of years ago. The mechanism has been there, pesign can sign modules. Now, asking Fedora to trust that key is a different issue, but users have to reboot after installing the nvidia drivers anyway, so clicking to accept the key isn't too much of a hurdle to jump through at that point.
Create key, enroll key, confirm enrollment, sign the binary with on-going signing requirement, lose signing key, make new signing key, no room in NVRAM for additional signing key, remove key, enroll key, confirm key.... it's shit. Not complete shit, but almost complete shit. And that's excluding running into bugs (pretty common to find myriad UEFI implementation bugs).
Ironically, only computers certified by Microsoft as part of their marketing program are also required to have a minimum user interface. There's a large pile of non-Microsoft certified hardware out there and they don't have to follow those requirements and often don't. Remarkably, right now you have to disable Secure Boot on Apple hardware because they don't even offer a way to enroll keys. They only include the key used for running Windows, not the key used for signing Fedora's shim bootloader.
As much of a Secure Boot fanboy I've been, I'm rapidly approaching the "fuck it" stage, because the burden is too high. I don't do anywhere near as much kernel regression testing because (a) I don't want to disable Secure Boot and (b) I'm unwilling to go through the hurdles to sign the kernel with my own key.