Thanks for the analysis and confirmation! :-) On Thu, Sep 08, 2022 at 04:16:16PM +0200, Cyril Brulebois wrote: >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 ([email protected]) <https://debamax.com/> >D-I release manager -- Release team member -- Freelance Consultant
-- Steve McIntyre, Cambridge, UK. [email protected] "War does not determine who is right - only who is left." -- Bertrand Russell
