This is mostly for the helpers, as the F44 release might lead to some topic about SecureBoot users no longer being able to boot after upgrading to F44:
I just was made aware in the devel channel that F44 is likely to become the first Fedora release that is signed with a new certificate (of 2023). There is dual-signing in place. But due to potential issues/bugs in some UEFI implementations, this in some cases can cause unexpected behavior, in which an UEFI might not be able to verify the kernel with a signature it knows (even if the old one is still there) if it is not up to date and thus might only know one of the signatures.
Therefore, just a short heads-up, in case such topics come up. I donāt know if anyone will create a common issue for this.
There is no general solution / work around. The first step is to update such an UEFI and its database, based on how to do it with the very device/vendor, in order to not trigger a bug if there is one. Or alternatively, fix the bug with the vendor.
Generally, this should work. The issue was put forward because related issues in UEFIs seem to have been known in several cases. So itās actually not a Fedora problem, so there is no general Fedora solution for it.
An illustrative case (I make this up as example) might be if the vendor does not sufficiently test dual-signatures, and while it might work fine with 1 signature, the UEFI might fail with 2 if one signature is known and the other not, and instead of rather using the one that is known (=verification works fine), it breaks / rejects.
This is just a preventive measure, in case such cases come up. It is not expected that this becomes a major wave of incidents or so: I brought it up only as such cases might be to helpers not obvious at first glance, and the fact that upgrading to F44 introduces the issue might be misleading without further information.
You can check if you already have the 2023 certificates by running
mokutil --list-enrolled --db --short
which should include
46def63b5c Microsoft Corporation UEFI CA 2011
580a6f4cc4 Microsoft Windows Production PCA 2011
b5eeb4a670 Microsoft UEFI CA 2023
3fb39e2b8b Microsoft Option ROM UEFI CA 2023
The certificates gets updated using fwupd directly or indirectly via Gnome Software or similar. They can also be update via Windows updates which may be better if you are dual booting with Windows.
Is there an easy way for users to revert to the previous shim if they discover that the new dual-signed one does not work?
Iām sure it is too late now, but IMHO, the update process should have renamed the previous shim to shim.efi.bak or something so that a user could (semi) easily revert the update if they found it didnāt work with their system.
I guess this is a pretty rare occasion, but it might be nice to have shell<arch>.efi on the ESP so people could do simple file renames in cases where their bootloader did not work.[1] Also, if UKIs become a common thing, that shell might be useful for loading older versions. I wonder if it is possible to pass parameters to those UKIs when loading them from that interactive shell?
At the moment, it is good to keep the possibility in mind, to ensure we donāt end up in misleading circles in topics if they come up, but as we do not yet know if it comes up at all, I would be careful to ask maintainers to develop mitigations for something we donāt know for sure if it comes up at all.
But if it happens, it might be indeed worth to early forward this to devel and ask for alternatives. I expect if that really breaks some users systems, and if we cannot easily update their UEFI/database, we will find a way / mitigation for the very audiences, but then with the exact data of the very cases (at the moment, we could only work with assumptions of how such a case might manifest ā inefficient). Letās hope this topic will not become relevant
