On Tue, Apr 5, 2022 at 6:39 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez <jaredz@xxxxxxxxxx> wrote: > > > The security of UEFI systems is immeasurably better. Standardized firmware updates, support for modern secure TPMs, OS protection from firmware (SMM mitigations), HTTP(S) boot support, largely shared and open sourced firmware codebases that aren't a pile of assembly code, and a lot of other features are UEFI-only. > > When users have a suboptimal experience by default, it makes Fedora > look bad. We can't have security concerns overriding all other > concerns. But it's really pernicious to simultaneously say security is > important, but we're also not going to sign proprietary drivers. This > highly incentivizes the user to disable Secure Boot because that's so > much easier than users signing kernel modules and enrolling keys with > the firmware, and therefore makes the user *less safe*. > > > >> And the amount of resistance to improving UEFI experience for hardware > >> is amazingly awful. The workstation working group has tried to figure > >> out ways to improve the experience, only to be simultaneously stymied > >> by the UEFI firmware management tools and unwillingness by anyone > >> involved to even consider that we should make this better. > > > > > > Which tools? What specific efforts have been stymied? How is any of this specific to UEFI versus trying to deal with things that aren't supported by someone? > > Namely, Fedora signing NVIDIA's proprietary driver. > > 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. 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? Justin _______________________________________________ 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
