[Bug 1955386] Re: fwupd / fwupd-efi split on version 1.7.x

Launchpad Bug Tracker 1955386 at bugs.launchpad.net
Tue Jun 20 07:41:56 UTC 2023


This bug was fixed in the package fwupd-signed - 1.51.1~18.04.1

---------------
fwupd-signed (1.51.1~18.04.1) bionic; urgency=medium

  * Rebuild against fwupd-efi 1:1.4-0ubuntu0.1 (LP: #2011808)
  * Install binaries to /usr/lib/fwupd on bionic for compatibility with
    fwupd 1.2.

fwupd-signed (1.51) lunar; urgency=medium

  * Remove i386 and armhf from the architecture list
  * Check that we are signing the correct version of fwupd and it is not revoked

fwupd-signed (1.48) lunar; urgency=medium

  [ Julian Andres Klode ]
  * Rebuild for 2022v1 resigning (LP: #2003365)

  [ Andy Whitcroft ]
  * Fix signing artifact download when faced with an authenticated archive
    pool.  Switch to using common download-signed from grub2/kernel.

fwupd-signed (1.44) jammy; urgency=medium

  * Built-Using must reference the source package, not binary packages.
  * Manually include the epoch in the version number for Built-Using,
    since for some reason this is not included in the version file published
    for the EFI binaries.

fwupd-signed (1.43) jammy; urgency=medium

  * remove fwupd-unsigned from Recommends of fwupd-signed deb. (LP:
#1960783)

fwupd-signed (1.42) jammy; urgency=medium

  * Adjust dependency requirements.  Since the package is decoupled from
    fwupd now, the version it needs to depend on doesn't need to match
    the package version.

fwupd-signed (1.41) jammy; urgency=medium

  * Build depends on fwupd-unsigned 1:1.1-3 (LP: #1955386)
  * Adjust download script to download candidate version instead of from
    "current" symlink

 -- Julian Andres Klode <juliank at ubuntu.com>  Tue, 07 Mar 2023 13:32:57
+0100

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to fwupd-signed in Ubuntu.
https://bugs.launchpad.net/bugs/1955386

Title:
  fwupd / fwupd-efi split on version 1.7.x

Status in OEM Priority Project:
  Fix Released
Status in fwupd package in Ubuntu:
  Fix Released
Status in fwupd-efi package in Ubuntu:
  Fix Released
Status in fwupd-signed package in Ubuntu:
  Fix Released
Status in fwupd source package in Bionic:
  Fix Released
Status in fwupd-signed source package in Bionic:
  Fix Released
Status in fwupd source package in Focal:
  Fix Released
Status in fwupd-signed source package in Focal:
  Fix Released
Status in fwupd source package in Impish:
  Fix Released
Status in fwupd-signed source package in Impish:
  Won't Fix

Bug description:
  [Impact]
  As the current fwupd is 1.7.x and it's fwupd / fwupd-efi source pkg has been splited, we need a new way of packaging and landing those in ubuntu.

  Likewise, on bionic we want to move to newer signed fwupd-efi binaries.
  [Test plan]
  Install fwupd-signed built from fwupd-efi and the new fwupd and check that it creates boot entry. We patched out building the UEFI binary only but kept the plugin, so we need to ensure the plugin still works correctly.

  [Where problems could occur]
  Could have messed up disabling the UEFI bits and then people can't do UEFI firmware upgrades anymore.

  [Other info]
  We do not have a task for fwupd-efi as it is binary copied and we can't add it to the changelog.

  [[bionic]]
  On bionic the implementation is as follows (which differs from later branches where we backported 1.7):

  - src:fwupd continues to build unsigned binaries and installs them,
  but does not submit them for signing.

  - src:fwupd-unsigned binaries are not installable together with fwupd,
  as fwupd < 1.7.7 is broken due to them locating the binaries in
  /usr/libexec. Hence they are only used as building input and not
  installed on end user systems. They don't have to be: insecure systems
  can continue to use the stub shipped in fwupd itself (previous point).

  - fwupd-signed is no longer provided on i386 and armhf. It is built
  from the binary-copied fwupd-efi now.

  How does this impact users?

  - Users without fwupd-signed installed will continue to use the old
  EFI stub shipped by fwupd itself.

  - Users on amd64 and arm64 with fwupd-signed installed will receive an
  upgrade to the fwupd-signed built from fwupd-efi 1.4. If secure boot
  is disabled, they'll continue to use fwupd's old EFI stub as fwupd
  only uses the .signed one if secure boot is enabled.

  - Users on i386 and armhf with fwupd-signed installed will remain with
  their installed fwupd-signed version.

  - Users on i386 and armhf installing fwupd freshly will pull in an
  older version of fwupd-signed from security until the new fwupd is
  released there. Not optimal. However, fwupd does not look for the
  .signed version if the boot was not secure.

  Alternatives:

  - We can add Breaks: fwupd-signed (<< 1.51) to fwupd, however this
  might be ill-advised: We want to make sure that the update to fwupd is
  actually being installed by apt upgrade and not kept back due to APT
  deciding keeping fwupd-signed installed is more important (on i386,
  armhf).

  - We can make fwupd always use a .signed version if available.
  Possibly later versions do. Introduces unnnecessary regression
  potential.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1955386/+subscriptions




More information about the foundations-bugs mailing list