On Wed, Jul 09, 2025 at 08:38:09AM -0700, Adam Williamson wrote: > On Wed, 2025-07-09 at 13:38 +0000, Richard Hughes via devel wrote: > > In the pathological case at least one vendor has lost the private key used for signing their PK, so they're having to issue firmware updates to replace the PK on the running system -- which could be a terrible idea from an attestation point of view. Those kind of vendors are also not the kind of vendors that usually issue bios updates (usually because of "cost") so the solution there is to turn off secure boot. If you're running a 7 year old system firmware then UEFI secure boot certificates are probably quite low on your compliance list. > > In theory wouldn't we also have the option to ship an old shim for such > cases? If the whole chain is old it should work, right? Of course, we'd > then need some heuristic to figure out if we're on the old MS cert and > install the old shim... That approach might work for a while, but will break with the first security-related shim update which gets signed with the new microsoft keys only. Continuing running shim with known security bugs makes it kida pointless to have secure boot turned on ... > I don't know if this is *worth it* vs just advising people to turn off > SB... I'd suggest the latter. take care, Gerd -- _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
