shim 15.7 and key rotation woes

[Julian Andres Klode]

Hi folks,

we'll soon be uploading shim 15.7, with 22.04.2 in mind specifically.
In this upload we have revoked all currently used keys basically, so
we need to do our best to ensure that users do not end up with
unbootable systems.

We started resigning all fwupd, grub with the new 2022v1 signing key
(note that we only sign grub 2.06 with the new keys, not older
versions, hence 2.06 is now in focal and bionic proposed pockets). The
kernel team will be signing kernels with the new key shortly.

shim-signed will Breaks old fwupd and grub versions.

We cannot 'Breaks' the kernels due to various reasons (like there's
tons of them and the metapackages don't have a Protected/Important
flag set so they are removable by apt).

Now how do we enforce that we don't update the shim on the ESP when we
don't have kernels trusted by it? One thing is clear: In the
maintainer script we need to check which kernels are signed by our CA
and see if all of them are in the revoked kernels (if you only have
self-signed kernels, or no signed kernels or whatever we don't care
about it in the context of this key revocation).

Option 1: Fail in preinst

This breaks a large apt upgrade in the middle leading to apport errors
and unconfigured packages on the system as apt doesn't complete
unrelated tasks necessarily.

Option 2: Backup and restore

In preinst we
   cp /usr/lib/shim/shimx64.signed /usr/lib/shim/shimx64.signed.bak
In postinst, we check if no trusted kernel is around and do
  cp /usr/lib/shim/shimx64.signed /usr/lib/shim/shimx64.signed.new
  cp /usr/lib/shim/shimx64.signed.bak /usr/lib/shim/shimx64.signed
if a trusted kernel is there, we do
  rm /usr/lib/shim/shimx64.signed.bak
instead.

Effectively restoring the previously installed shim.

In a kernel postinst.d hook we then do a
  mv /usr/lib/shim/shimx64.signed.new /usr/lib/shim/shimx64.signed
  rm /usr/lib/shim/shimx64.signed.bak

when installing a trusted kernel.

Option 3: Alternatives

We ship both the latest and previous shim in shim-signed, install them
both as alternatives. If trusted kernels are around, the 'latest'
alternative gets priority 100 and the 'previous' gets priority 50;
without trusted kernels the priorities are reversed.

We then add a kernel postinst.d hook that swaps the priorities and
reconfigures shim-signed (installs it to the ESP) when a trusted
kernel is being installed.

Option 4: Hybrid

Basically we install both latest and previous as with alternatives,
but manage the symlink ourselves instead of having it configurable as
alternatives.

Evaluation:

1. Potential for a lot of annoyance
2. I expect enterprisy folks to run stuff like dpkg -V and flag that
as intrusion
3. It's a bit whimsical for it to be configurable, but it also going
forward will allow us to install both the old and new shims so that
UEFI can fallback in case a new shim is broken (a/b boot).
4. Less whimsical than 3 but slightly higher potential of messing this
up if we do it ourselves rather than run 2 lines of
update-alternatives.

Hence why I am leaning towards 3.