| 2021-12-20 06:36:41 |
Yuan-Chen Cheng |
bug |
|
|
added bug |
| 2021-12-20 06:36:58 |
Yuan-Chen Cheng |
bug task added |
|
oem-priority |
|
| 2021-12-20 06:37:04 |
Yuan-Chen Cheng |
oem-priority: importance |
Undecided |
Critical |
|
| 2021-12-20 06:37:06 |
Yuan-Chen Cheng |
oem-priority: assignee |
|
Yuan-Chen Cheng (ycheng-twn) |
|
| 2021-12-20 06:37:12 |
Yuan-Chen Cheng |
oem-priority: status |
New |
In Progress |
|
| 2022-01-03 19:06:29 |
Mario Limonciello |
bug task added |
|
fwupd-efi (Ubuntu) |
|
| 2022-01-04 17:28:15 |
Mario Limonciello |
fwupd-efi (Ubuntu): status |
New |
Fix Released |
|
| 2022-01-04 18:33:41 |
Mario Limonciello |
bug task added |
|
fwupd-signed (Ubuntu) |
|
| 2022-01-04 18:48:08 |
Mario Limonciello |
fwupd-signed (Ubuntu): status |
New |
Fix Released |
|
| 2022-01-07 14:48:59 |
Mario Limonciello |
fwupd (Ubuntu): status |
New |
Fix Released |
|
| 2022-01-17 09:04:37 |
Rex Tsai |
tags |
fwupd |
fwupd oem-priority |
|
| 2022-01-17 12:22:18 |
Yuan-Chen Cheng |
oem-priority: status |
In Progress |
Fix Released |
|
| 2022-02-07 13:13:12 |
Yuan-Chen Cheng |
oem-priority: status |
Fix Released |
In Progress |
|
| 2022-02-08 05:31:15 |
Yuan-Chen Cheng |
attachment added |
|
fwupd-signed-impish-ar.tgz https://bugs.launchpad.net/oem-priority/+bug/1955386/+attachment/5559651/+files/fwupd-signed-impish-ar.tgz |
|
| 2022-02-08 05:31:38 |
Yuan-Chen Cheng |
attachment added |
|
fwupd-signed-focal-ar.tgz https://bugs.launchpad.net/oem-priority/+bug/1955386/+attachment/5559652/+files/fwupd-signed-focal-ar.tgz |
|
| 2022-02-08 16:36:13 |
Łukasz Zemczak |
fwupd-signed (Ubuntu Impish): status |
New |
Fix Committed |
|
| 2022-02-08 16:36:14 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-02-08 16:36:15 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2022-02-08 16:36:18 |
Łukasz Zemczak |
tags |
fwupd oem-priority |
fwupd oem-priority verification-needed verification-needed-impish |
|
| 2022-02-08 16:37:47 |
Łukasz Zemczak |
fwupd-signed (Ubuntu Focal): status |
New |
Fix Committed |
|
| 2022-02-08 16:37:51 |
Łukasz Zemczak |
tags |
fwupd oem-priority verification-needed verification-needed-impish |
fwupd oem-priority verification-needed verification-needed-focal verification-needed-impish |
|
| 2022-02-09 03:14:05 |
Yuan-Chen Cheng |
tags |
fwupd oem-priority verification-needed verification-needed-focal verification-needed-impish |
fwupd oem-priority verification-done-focal verification-needed verification-needed-impish |
|
| 2022-02-28 12:48:48 |
Łukasz Zemczak |
fwupd (Ubuntu Impish): status |
New |
Fix Committed |
|
| 2022-02-28 14:10:12 |
Łukasz Zemczak |
fwupd (Ubuntu Focal): status |
New |
Fix Committed |
|
| 2022-02-28 14:10:17 |
Łukasz Zemczak |
tags |
fwupd oem-priority verification-done-focal verification-needed verification-needed-impish |
fwupd oem-priority verification-needed verification-needed-focal verification-needed-impish |
|
| 2022-03-01 14:22:56 |
Yuan-Chen Cheng |
tags |
fwupd oem-priority verification-needed verification-needed-focal verification-needed-impish |
fwupd oem-priority verification-done-impish verification-needed verification-needed-focal |
|
| 2022-03-01 22:14:37 |
Yuan-Chen Cheng |
tags |
fwupd oem-priority verification-done-impish verification-needed verification-needed-focal |
fwupd oem-priority verification-done verification-done-focal verification-done-impish |
|
| 2022-03-01 22:14:58 |
Yuan-Chen Cheng |
oem-priority: status |
In Progress |
Fix Committed |
|
| 2022-03-10 17:04:49 |
Launchpad Janitor |
fwupd (Ubuntu Impish): status |
Fix Committed |
Fix Released |
|
| 2022-03-10 17:05:36 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2022-03-10 17:07:58 |
Launchpad Janitor |
fwupd (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2022-03-10 17:09:11 |
Launchpad Janitor |
fwupd-signed (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2022-06-29 01:33:54 |
Yuan-Chen Cheng |
oem-priority: status |
Fix Committed |
Fix Released |
|
| 2022-07-18 23:03:38 |
Brian Murray |
fwupd-signed (Ubuntu Impish): status |
Fix Committed |
Won't Fix |
|
| 2023-03-16 11:15:13 |
Julian Andres Klode |
nominated for series |
|
Ubuntu Bionic |
|
| 2023-03-16 11:15:13 |
Julian Andres Klode |
bug task added |
|
fwupd (Ubuntu Bionic) |
|
| 2023-03-16 11:15:13 |
Julian Andres Klode |
bug task added |
|
fwupd-signed (Ubuntu Bionic) |
|
| 2023-03-16 11:15:13 |
Julian Andres Klode |
bug task added |
|
fwupd-efi (Ubuntu Bionic) |
|
| 2023-03-16 11:15:31 |
Julian Andres Klode |
bug task deleted |
fwupd-efi (Ubuntu Bionic) |
|
|
| 2023-03-16 11:23:20 |
Julian Andres Klode |
description |
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. |
[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.
[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. |
|
| 2023-03-16 11:23:48 |
Julian Andres Klode |
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, so we stop building the EFI binaries in src:fwupd despite still being in the source.
[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. |
[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.
[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. |
|
| 2023-03-28 13:28:53 |
Julian Andres Klode |
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, so we stop building the EFI binaries in src:fwupd despite still being in the source.
[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. |
[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).
- 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. |
|
| 2023-03-28 13:30:16 |
Julian Andres Klode |
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. 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. |
[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. Not optimal. |
|
| 2023-03-28 13:36:13 |
Julian Andres Klode |
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. 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. Not optimal. |
[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). |
|
| 2023-03-29 08:14:22 |
Julian Andres Klode |
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). |
[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. 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.
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). |
|
| 2023-03-29 08:16:09 |
Julian Andres Klode |
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. 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.
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). |
[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. |
|
| 2023-05-31 16:22:25 |
Łukasz Zemczak |
fwupd-signed (Ubuntu Bionic): status |
New |
Fix Committed |
|
| 2023-05-31 16:22:27 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-05-31 16:22:31 |
Łukasz Zemczak |
tags |
fwupd oem-priority verification-done verification-done-focal verification-done-impish |
fwupd oem-priority verification-done-focal verification-done-impish verification-needed verification-needed-bionic |
|
| 2023-05-31 16:24:16 |
Łukasz Zemczak |
fwupd (Ubuntu Bionic): status |
New |
Fix Committed |
|
| 2023-06-07 13:14:34 |
Julian Andres Klode |
tags |
fwupd oem-priority verification-done-focal verification-done-impish verification-needed verification-needed-bionic |
fwupd oem-priority verification-done-bionic verification-done-focal verification-done-impish verification-needed |
|
| 2023-06-20 07:41:46 |
Launchpad Janitor |
fwupd (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2023-06-20 07:41:56 |
Launchpad Janitor |
fwupd-signed (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
