Re: Analysis: mismatched shim* packages vs. debian-installer (opu/pu)
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 (kibi@debian.org) <https://debamax.com/>
>D-I release manager -- Release team member -- Freelance Consultant
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"War does not determine who is right - only who is left."
-- Bertrand Russell
Reply to: