Can you please explain exactly what versions you had in mind to backport to
exactly what releases? Is this fwupd | 2.0.19-1ubuntu2 from resolute going
to questing, noble, jammy? The same for libjcat and libxmlb?
What about focal, bionic, xenial? trusty? Would this go to the primary archive,
or to the esm archive?
Would this change to the 2023 CA break booting for older images? Do all images
need to be respun to new point releases?
Looking at the rdepends of fwupd, libjcat and libxml, gnome-software is a clear
user of these packages. Is gnome-software on these stable releases compatible
with the new packages? Ubuntu itself does not rely on gnome-software, but I
assume there are official and non official flavours that do.
Do you have a brief list of commits that you investigated when you decided it
was not practical to backport to previous fwupd releases? How many
patches is it?
Have you spoken to Richard Hughes and Mario Limonciello upstream about how we
should go about solving this problem? From what I can see, the 1_9_X branch is
still active. How about getting upstream to backport patches to that branch and
make a release? Is it even possible?
In your [Testcase], this will need more than a basic functionality smoketest.
Have you spoken to the Hardware Certification Lab about getting some test
hardware you can use various releases like focal, jammy, etc to perform real
firmware updates on? Just testing a basic CA upgrade in a VM doesn't quite feel
enough testing for real world usage.
I think this is a good starting point for discussion.
Thanks,
Matthew and Christopher
On Wed, 25 Feb 2026 at 10:54, Mate Kukri <mate.kukri@canonical.com> wrote:
>
> Hello,
>
> I am writing to ask for feedback on a proposed major version update to
> fwupd, libxmlb, and libjcat in our stable releases (mainly 22.04 LTS
> and 24.04 LTS).
>
> As many of you are likely aware, the Microsoft 3rd Party UEFI CA 2011
> is set to expire in July 2026. This CA starts the Secure Boot chain
> for the vast majority of Ubuntu devices. To prevent devices from
> failing to upgrade to newer bootloader security updates or losing the
> ability to process revocations after this date, we must roll out the
> new 2023 UEFI CA and KEK.
>
> The industry-standard mechanism for delivering these DB/KEK updates on
> Linux is via fwupd and LVFS. However, the versions of fwupd currently
> in our stable releases are too old to support this specific update
> mechanism.
>
> To address this, I am proposing a backport of the latest stable fwupd
> version (along with its tight dependencies libxmlb and libjcat).
>
> I realize this "large hammer" approach deviates from the usual Stable
> Release Update (SRU) regarding major version bumps. However, I have
> evaluated alternative options, such as backporting only the DB/KEK
> update logic, and found them excessively fragile and difficult to
> maintain. Given the critical nature of the CA expiry, I believe
> ensuring users can easily transition to the new trust outweighs the
> regression risks of a version update. Beyond SRU, this will eventually
> need to be copied to security pockets, so that devices running only
> security updates can receive a new shim when necessary.
>
> I have a work-in-progress bug here:
> https://bugs.launchpad.net/ubuntu/+source/libxmlb/+bug/2142578
>
> I would appreciate any feedback or concerns regarding this approach
> before proceeding further.
>
> Thanks,
> Mate Kukri
>
> --
> Ubuntu-release mailing list
> Ubuntu-release@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
