Hi Julian, On 21/08/2024 12:16, Julian Andres Klode wrote:
Source: grub2 Version: 2.12-5ubuntu4 Severity: wishlist X-Debbugs-Cc: j...@debian.org, debian-rele...@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
