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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue