Bug#1079202: Refactoring grub2 into versioned packages

[Julian Andres Klode]

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.

-- System Information:
Debian Release: trixie/sid
  APT prefers oracular
  APT policy: (500, 'oracular'), (100, 'oracular-proposed')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.0-31-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-grub-devel/attachments/20240821/52d7f7e7/attachment.sig>