Proposal for exception to existing fwupd SRU policy

[Mario Limonciello]

Hello,

The existing agreed upon SRU policy for firmware updates (firmware-updates
- Ubuntu Wiki <https://wiki.ubuntu.com/firmware-updates>) allows for
updating the fwupd/fwupdate stack as necessary within a given stable
release series.  This strategy has worked well for a good period of time,
but recently there have been several things that have changed putting it's
efficacy into question.

First: Although OEMs are enabling new hardware with LTS releases, new fwupd
plugins are developed that can support firmware updates for such hardware
only in newer fwupd versions.  This means that even though an OEM launches
a system with Ubuntu LTS typically customers won't be able to get firmware
updates for new device types until the next LTS release.  To give you an
idea how many new device types have been introduced:
Fwupd 1.3.x supported 44 plugins
Fwupd 1.4.x supported 47 plugins
Fwupd 1.5.x supports 66 plugins
>From this limitation it's not possible to distribute a security update to
some devices that are in the field.  Some example issues that this causes
(not at all complete):
1) To be more Agile, Dell can distribute microcode security upgrades
separately from BIOS upgrades for selected systems that ship with Ubuntu,
but this requires fwupd 1.4.0 or later to be upgradable.
2) Synaptics has a fingerprint reader that can be updated, but it requires
fwupd 1.4.6 or later.  This issue is summarized in Bug #1900935 “Support to
upgrade Synaptic fingerprint firmware f...” : Bugs : fwupd package : Ubuntu
(launchpad.net)
<https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1900935>

Second: As fwupd and LVFS have grown, a larger CDN infrastructure has been
adopted.  This has been largely a good thing, but it's shown some problems
related to the timing of the CDN cache being updated.  If poor timing is
adopted between the signing of the firmware metadata and creation of that
metadata a bad pair will land on some of the CDN leading to users unable to
perform firmware upgrades.  This issue has been compounded by the fact that
fwupd 1.3.x has introduced support to display in the motd the availability
of firmware upgrades.  This is accomplished by a systemd service that will
refresh metadata if it's not already updated by another client and then
update the motd.  If this process fails due to the CDN having invalid data
the service has a "1" return code and some users have complained on this
issue when it occurs.
This has been fixed in the 1.4.x and later version via a new architecture
for metadata signing and distribution.  Individual metadata will not be
invalidated, preventing cache misses or things getting out of sync.
All of this is summarized in Bug #1909603 “Occasionally
fwupd-refresh.service: Failed with re...” : Bugs : fwupd package : Ubuntu
(launchpad.net)
<https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1909603> as discussed
in larger detail in other bugs and complaints it links to in upstream.

Because of this collection of issues and the expectation that more devices
will be supported by newer versions of the stack again in the future, I'm
wondering if we should adopt a different policy for firmware update
utilities to allow moving to a newer version of the stack in LTS releases.
I would like input from the technical board on this.

One more thing I'd like to note: If moving to a newer release is the
direction that the technical board chooses to go, moving to a newer version
of the stack (1.4.x or later) in Ubuntu 20.04 will require a MIR for
libjcat.
This MIR already happened for later releases.

Thanks,

-- 
Mario Limonciello
superm1 at ubuntu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20210114/da3a7077/attachment.html>