Re: Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Michael Biebl <mbiebl@xxxxxxxxx>]

Am Mi., 27. Apr. 2022 um 18:02 Uhr schrieb Michael Biebl <mbiebl@xxxxxxxxx>:
>
> Am Mi., 27. Apr. 2022 um 17:16 Uhr schrieb Dan Nicholson <dbn@xxxxxxxxxxxxx>:
> >
> > On Wed, Apr 27, 2022 at 9:01 AM Michael Biebl <mbiebl@xxxxxxxxx> wrote:
> > >
> > > Slightly related
> > > https://salsa.debian.org/systemd-team/systemd/-/merge_requests/138
> > > [sd-boot split]
> > > https://salsa.debian.org/systemd-team/systemd/-/merge_requests/132
> > > [Draft: Prepare for EFI signing]
> >
> > Oh, nice. We've been signing sd-boot in Endless for a couple years now
> > with our systemd package based on Debian's. Currently the entire
> > systemd package is sent through the signing flow just for sd-boot.
> > When sd-boot is a separate package that can be much simpler with the
> > normal non-sd-boot targets unaffected.
>
>
> This discussion  might be relevant to  you then
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996202
>
> Automatically signing sd-boot in Debian was rejected by Julian Andres Klode

>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.

We reject a signing of systemd-boot as

* systemd-boot does not use current ways of communicating with
  shim

* There was some concern over general quality

* systemd-boot is an additional bootloader, rather than replacing
  an existing one, thus increasing the attack surface.

  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.
"""