Hi, This is just a summary (TL;DR at the bottom) of my findings from the past few days, while preparing d-i for the upcoming point releases. I thought I would share in case anyone (e.g. future self) wonders what might happen again in the future if we get unlucky again. I'll focus on bullseye but buster is similar.
I've said a few times to my fellow release team members that packages in
(old-)proposed-updates could be accepted without an explicit ACK from me
since we could side-step buggy packages by feeding our apt calls some
pinning, preferring udebs from (old-)stable over those in (old-)p-u if
we spotted some problems during pre-upload building and testing.
That doesn't work for packages that we list in Build-Depends, and
buildds have (old-)p-u configured, so we end up pulling packages from
there as long as they're installable.
For shim* packages, that means the following, mismatched packages when
building the debian-installer package:
Get: 138 http://deb.debian.org/debian bullseye-proposed-updates/main amd64
shim-unsigned amd64 15.6-1~deb11u1 [439 kB]
Get: 139 http://deb.debian.org/debian bullseye-proposed-updates/main amd64
shim-helpers-amd64-signed amd64 1+15.6+1~deb11u1 [301 kB]
Get: 140 http://deb.debian.org/debian bullseye/main amd64
shim-signed-common all 1.38+15.4-7 [13.6 kB]
Get: 141 http://deb.debian.org/debian bullseye/main amd64 shim-signed amd64
1.38+15.4-7 [320 kB]
It's likely affecting all architectures where the d-i build pulls shim
packages (but I didn't check further than amd64):
shim-signed [amd64 i386 arm64]
To be extra sure, I've tried putting version restrictions to stick
to bullseye packages, but sbuild/apt bail out with broken packages,
as expected:
sbuild-build-depends-main-dummy : Depends: shim-unsigned (< 15.6-1~deb11u1)
but 15.6-1~deb11u1 is to be installed
Depends: shim-helpers-amd64-signed (<
1+15.6+1~deb11u1) but 1+15.6+1~deb11u1 is to be installed
I've verified two things:
- switching to the non-default aptitude resolver lets sbuild find a
solution, but that could have other side effects (that I didn't
investigate);
- introducing pinning in the chroot configuration lets us stick to
bullseye packages, affecting only shim* packages.
Of course, both rely on having admins around to tweak the config for
that particular build, which is far from ideal.
Let's see what shim packages look like:
1. shim-unsigned /usr/lib/shim/BOOTX64.CSV
shim-unsigned /usr/lib/shim/fbx64.efi
shim-unsigned /usr/lib/shim/mmx64.efi
shim-unsigned /usr/lib/shim/shimx64.efi
2. shim-helpers-amd64-signed /usr/lib/shim/fbx64.efi.signed
shim-helpers-amd64-signed /usr/lib/shim/mmx64.efi.signed
3. shim-signed /usr/lib/shim/shimx64.efi.signed
4. shim-signed-common /usr/sbin/update-secureboot-policy
And the combination above is permitted due to lax version dependencies.
As far as I understand (and `sbverify --list` on each `*.signed` file
seems to agree), (1) gets uploaded, results in (2) getting signatures
from the Debian infrastructure; while (3) and (4) need manual MS
approval and signature.
In the debian-installer tree, after a build, there are no traces of shim
anywhere, which was a bit surprising at first; but it turns out that
build/util/efi-image is the sole user of shim files, and it concentrates
on /usr/lib/shim/shim<arch>.efi.signed, from the shim-signed binary, but
copying it under a different name in the build tree:
https://salsa.debian.org/installer-team/debian-installer/-/blob/20210731+deb11u5/build/util/efi-image#L147-148
https://salsa.debian.org/installer-team/debian-installer/-/blob/20210731+deb11u5/build/util/efi-image#L156-157
TL;DR: Everything matches what was already assessed by Steve McIntyre:
mismatched shim* packages shouldn't be an issue from a d-i perspective,
we're “just using the old shim” (sorry, buster…).
Cheers,
--
Cyril Brulebois (k...@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
