On Thu, Apr 7, 2022 at 9:20 AM Simo Sorce <simo@xxxxxxxxxx> wrote: > > On Wed, 2022-04-06 at 21:03 -0500, Justin Forbes wrote: > > On Wed, Apr 6, 2022 at 6:31 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > > > > > On Wed, Apr 6, 2022 at 10:23 AM Justin Forbes <jmforbes@xxxxxxxxxxx> wrote: > > > > > > > > Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all > > > > > indicate Apple and Microsoft trust the driver itself. It is trusting > > > > > the providence of the blob, in order to achieve an overall safer > > > > > ecosystem for their users. > > > > > > > > > > We either want users with NVIDIA hardware to be inside the Secure Boot > > > > > fold or we don't. I want them in the fold *despite* the driver that > > > > > needs signing is proprietary. That's a better user experience across > > > > > the board, including the security messaging is made consistent. The > > > > > existing policy serves no good at all and is double talk. If we really > > > > > care about security more than ideological worry, we'd sign the driver. > > > > > > > > At the very least, it would require that Fedora have a separate key > > > > that is trusted and not the same one used for shim/grub/kernel. > > > > > > If Fedora is going to sign it, rather than improving the local signing > > > experience, absolutely it should be signed with a separate key. The > > > design should assume a revocation is going to happen at some point. > > > > > > > We > > > > certainly aren't proposing that we use the standard Fedora keys to > > > > sign a binary blob that runs in kernel space from a company who was > > > > most recently hacked last month? > > > > > > No way. > > > > > > I don't think there's a mechanism for it, but I'd prefer Fedora sign > > > the 3rd party's key rather than their binary. Maybe it's a small > > > distinction at the end of the day. > > > > > > 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. > > There is potentially an even easier solution. > Ideally dkms (or whatever) could simply generate a key, sign the module > and manage to get the public key in the right place so that the module > can be verified. But this is hard work I guess, and nobody cares about > Secure Boot enough to do it? > This has been done for a while. However, there are issues. The lack of ability to manage it in a non-interactive fashion, or even fully from the desktop UX because of having to deal with firmware key storage is a huge problem. But even if you get past that, there are problems where there isn't enough memory on the firmware flash storage for another key. This is one of the reasons why the SBAT strategy was devised for Secure Boot: running out of space for certs in firmware is a very real problem that people want to avoid. This is why an OS-level keyring for these things is needed: it allows us to scope it to the operating system (like Windows does), allows unique keys to be easily managed, and makes it easy to rotate them without worrying about causing problems. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
