On Mi, 27.04.22 18:57, Michael Biebl (mbiebl@xxxxxxxxx) wrote: > >From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996202#60 > > """ > we have recently discussed the matter of systemd-boot in > an upstream shim review gathering. Ominous. > We reject a signing of systemd-boot as > > * systemd-boot does not use current ways of communicating with > shim It does not? What does that even mean, and why does that even matter? Also, it does communicate with shim, see src/boot/efi/shim.c… And there's SBAT support, which is a shim thing afaik. > * There was some concern over general quality Humpf. That's just 1st rate FUD. I mean, if systemd for PID 1 is OK'ed by distros, then maybe the boot loader maintained by the same people should be fine too. i'd be curious what precisely the "quality" issues are supposed to be… > * systemd-boot is an additional bootloader, rather than replacing > an existing one, thus increasing the attack surface. Hmm, what? "additional bootloader"? Are they suggesting you use grub to start sd-boot? I mean, you certainly could do that, but the only people I know who do that do that to patch around the gatekeeping that the shim people are doing. Technically the boot chain should either be [firmware → sd-boot → kernel] or [firmware → shim → sd-boot → kernel] (if you buy into the shim thing), and nothing else. > If people want to experiment with other bootloaders than the > default one, they can disable secure boot, or load their own > keys into the machine. We do not consider it valid to have > a choice of bootloaders. > > I want to note that the current shim has been signed with the > understanding that it will trust grub, kernels, and fwupd. A > signing of systemd-boot might be considered reasons for revoking > the existing shim, and will certainly result in new shims not > getting signed. Christ! That's some gatekeeping. Lennart -- Lennart Poettering, Berlin