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

Reply via email to