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

[Julian Andres Klode]

** Description changed:

  [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,
- so we stop building the EFI binaries in src:fwupd despite still being in
- the source.
- 
+ 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.
+ 
+ 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. Systems will
+ continue to pull in an older -signed binary from -security until the new
+ fwupd-signed lands there (could arch restrict the Recommends to arm64
+ amd64).
+ 
+ - 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
+ 
+ - 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.

** Description changed:

  [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.
  
  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. Systems will
  continue to pull in an older -signed binary from -security until the new
  fwupd-signed lands there (could arch restrict the Recommends to arm64
  amd64).
  
+ 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
  
  - 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.
+ there. Not optimal.

-- 
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:
  New
Status in fwupd-signed source package in Bionic:
  New
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.

  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

  - 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.

  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).

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