[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:
>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…).
>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: