XPost: linux.debian.maint.boot
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 (
kibi@debian.org) <
https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmMZ+SoACgkQ/5FK8MKz VSBiBQ//ewSk05DpFYFISgejCQbLpEp6arWfuBPigsE6iMUEg0zq0prhmdJ6SnPT HIOG/7QOLwmoNVia136D0FEZJou3xCFUoq8bSD63g1vR7j/bZ5OoSSYPCm5bWjFL ILr5vTiDH4FUoNCnuJZmdr/qOPdfKrMEhputQqHME6W6U300+2dtgzWmjMx/Rfzw 0+6kn3ISonBwXXCCXogyiiLQaGQpecTd/KBzF7vBrY0/H/oT8FAPypaexvmw0q3P jU59FOvz+390pKVI5JB8qREGZRc+J7ULfatBCqFWSrxPIgy40dKaqm6E5cu0zMDf waxpvNl1ZMMRHic2wMwChXmioeb42sp66r4zaOAOb5WFJb+LTbk2UQkW+vC2DNRt fGACqNFHlDj4pKm93jIQMLSnAUQ+Blgto8gGcbd2UrFRGjbv0cQvoZLswDeT1Zp/ fHVwX9HO7Jf3LNBfS1ycKEk6QdK2mCYOi1U34sJ+ehF2DWPyidjOYLT5rHdXloZq LLvx7t5vfk9F/ICoMwQ0JHhzaUFssknSlYcEuaibk365teNlvmLOQXBI6rcmwqi3 oSBGkDvem9sjScE/I/6yqLgT0lYLRvUQfVwGA5UtAYxbhzs1FnIRkvtDp47EDVkA i572ZAd2YyRnlu0gaygl0k6hE1TVh8v+coMaXJxDhFwzVw7muGU=
=0iql
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
*