[Feature]: Please include an additional old-format dbx signed deliverable #154
Description
Feature Overview
This project takes a public (thanks!) JSON manifest then builds a dbx, which gets signed -- rather than the previous solution which seemed a bit of a hack. This is a much better solution and I thank everyone involved in the new way to build the dbx. Not revoking the PCA 2011 cert also makes this dbx much more useful than the one hosted on the UEFI page.
The new dbx in PostSignedObjects only include the per-arch hashes, rather than the old dbx which had the x64+ia32+aarch64 hashes (from before the dbx was made per-arch) so the new-style dbx is much smaller. This causes fwupd heartburn as the number of hashes went down (and so fwupd sees it as a downgrade) and this breaks deploying the update on RHEL. This prompted a flurry of work to no longer rely on the number of hashes in https://blogs.gnome.org/hughsie/2025/01/20/fwupd-2-0-4-and-dbxupdate-20241101/
which solves the problem upstream and in Fedora 42, but not in RHEL so I need to backport the new org.uefi.dbx2 protocol into Fedora 41 and probably all RHELs long term. We also need an interim solution for customers that don't want to wait for RHEL 9.7.
Solution Overview
We wondered if MS could publish an 'old format' all-arch style DBX that just appended the recent hashes for CVE-2024-7344 to make deploying the dbx update to RHEL easier? I think the root cause of the problem seems to be that the change of dropping the invalid-arch hashes should never have coincided with any actual security impacting changes for CVE-2024-7344. Perhaps this can just be "one more target" of the dbx like we already have for the optional PCA 2011 dbx revocations.
Adjacent to all this we would like to see how we (either as Red Hat, or LVFS) can pursue a more direct relationship to get access to these types of changes before release. The SUVP program seemed more like a program for large enterprises to validate windows updates, which isn't exactly what we want. I'm sure there's a way we can do this somehow. Any feedback welcome, thanks.
Alternatives Considered
There is an escape hatch of using fwupdtool install-blob DBXUpdate.bin which does all the fancy "check you've not got something blocked in your ESP" checks that we know and love. We can get the .bin by downloading the cab from the LVFS and decompressing it (or grabbing it from the PostSignedObject github page) but that's really clunky and can't be automated like fwupdmgr update can.
I wish I could upload the new-style dbx to the LVFS with the PostSignedObject using the old dbx "count the hashes" protocol and then make users do "fwupdmgr downgrade THE_GUID" which is probably a support nightmare, and might not even work at all as fwupd thinks the dbx can't be downgraded (which it normally can't).
Urgency
Medium
Are you going to implement the feature request?
Someone else needs to implement the feature
Do you need maintainer feedback?
Maintainer feedback requested