Bug#1079202: Refactoring grub2 into versioned packages

[Emilio Pozuelo Monfort]

Hi Julian,

On 21/08/2024 12:16, Julian Andres Klode wrote:
> Source: grub2
> Version: 2.12-5ubuntu4
> Severity: wishlist
> X-Debbugs-Cc: jak at debian.org, debian-release at lists.debian.org
> 
> (RT: This discusses the strategy to reduce regression risk for
> stable releases when we need to move towards new grub versions
> for security support)
> 
> This is mostly for discussion but as you are well aware, maintaining
> security support for grub can be challenging, the last big update, we
> instead backported the new grub to old releases.
> 
> Issue statements:
> 
> 1. Backporting the entire grub generates undue regression potential for
> platforms that don't have a secure boot workflow, such as BIOS systems.
> In Ubuntu, the signed EFI targets were split out into a grub2-unsigned
> package specifically to avoid having to update BIOS and other targets
> for security updates.
> 
> 2. This isn't enough though, we know 2.12 is causing more regressions
> and we might be able to support 2.06, so we'd want new systems to
> install 2.12, but existing systems to stay on 2.06 even for signed
> targets.
> 
> 3. On the flip side, some other targets that are not signed might need
> fixes for new hardware too, and you might want to install e.g.
> grub2.14's BIOS target because grub2.12 doesn't work reliably.
> 
> It is a bit hard to solve this now for 2.12, and 2.14 may come soon,
> hence let me propose the following implementation for 2.14 and how
> backports of 2.16/2.18 to trixie can then work:
> 
> We split src:grub2 into src:grub-defaults and src:grub2.14. The
> src:grub-defaults builds the meta packages, and src:grub2.14 builds
> the target binaries, e.g.
> 
>      src:grub-defaults builds
> 
>          grub-common
>          grub-efi-amd64
>          grub-efi-amd64-signed
>          grub-efi-amd64-unsigned
>          grub-pc
>          and so on
> 
>      src:grub2.14 builds
> 
>          grub2.14-common
>          grub2.14-efi-amd64-bin
>          grub2.14-efi-amd64-unsigned
>          grub2.14-efi-amd64-signed (via signing template)
>          grub2.14-pc-bin
>          and so on
> 
> The meta package structure looks like this:
> 
> 
>      Package: grub-efi-amd64
>      Depends: grub-efi-amd64-signed | grub-efi-amd64-unsigned
>      Protected: yes
> 
>      Package: grub-efi-amd64-signed
>      Depends: grub2.14-efi-amd64-signed
>      Protected: yes
> 
>      Package: grub-efi-amd64-unsigned
>      Depends: grub2.14-efi-amd64-unsigned
>      Protected: yes
> 
>      Package: grub-pc
>      Depends: grub2.14-pc-bin
>      Protected: yes
> 
> All the targets are Protected: yes to protect them from being removed,
> and the signed and unsigned package are too to protect that choice.
> 
> Now grub 2.16 comes along, and we end security support for 2.14, the
> patches are too hard to backport:
> 
>      Package: grub-efi-amd64
>      Depends: grub-efi-amd64-signed | grub-efi-amd64-unsigned
>      Protected: yes
> 
>      Package: grub-efi-amd64-signed
>      Depends: grub2.16-efi-amd64-signed
>      Protected: yes
>      ^ everyone with signed binary needs to upgrade
> 
>      Package: grub-efi-amd64-unsigned
>      Depends: grub2.16-efi-amd64-unsigned | grub2.14-efi-amd64-unsigned
>      Protected: yes
>      ^ new installs get 2.16, old installs remain on 2.14
> 
>      Package: grub-pc
>      Depends: grub2.16-pc-bin | grub2.14-pc-bin
>      Protected: yes
>      ^ new installs get 2.16, old installs remain on 2.14
> 
> Now grub 2.18 comes along and has huge regression potential, but we can
> still security support 2.16, so we do it different:
> 
>      Package: grub-efi-amd64-signed
>      Depends: grub2.18-efi-amd64-signed | grub2.16-efi-amd64-signed
>      Protected: yes
>      ^ new installs get 2.18, existing systems can stay on 2.16 for now
> 
>      Package: grub-efi-amd64-unsigned
>      Depends: grub2.18-efi-amd64-unsigned | grub2.16-efi-amd64-unsigned | grub2.14-efi-amd64-unsigned
>      Protected: yes
>      ^ new installs get 2.18, existing systems can stay on 2.16 or 2.14
> 
>      Package: grub-pc
>      Depends: grub2.18-pc-bin | grub2.16-pc-bin | grub2.14-pc-bin
>      Protected: yes
>      ^ new installs get 2.18, existing systems can stay on 2.16 or 2.14
> 
> I carefully constructed this so that we can move the ownership of
> running grub-install to the grub-efi-amd64 package and use triggers
> for any of the other packages.

This sounds like a reasonable approach to me.

Cheers,
Emilio