[systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Luca Boccassi]

On Wed, 2022-04-27 at 13:31 -0400, Neal Gompa wrote:
> On Wed, Apr 27, 2022 at 1:07 PM Neal Gompa <ngompa13 at gmail.com> wrote:
> > 
> > On Wed, Apr 27, 2022 at 12:19 PM Zbigniew Jędrzejewski-Szmek
> > <zbyszek at in.waw.pl> wrote:
> > > 
> > > On Wed, Apr 27, 2022 at 11:40:36AM -0400, Neal Gompa wrote:
> > > > On Wed, Apr 27, 2022 at 11:26 AM Dan Nicholson <dbn at endlessos.org> wrote:
> > > > > 
> > > > > On Wed, Apr 27, 2022 at 9:10 AM Neal Gompa <ngompa13 at gmail.com> wrote:
> > > > > > 
> > > > > > Note that it means Fedora CI, pull requests from contributors, and
> > > > > > releng auto-rebuilds will no longer work. Maintainers basically
> > > > > > sign-on to do all of those things manually and have to be responsive
> > > > > > for doing it. You will get FTBFS tickets every cycle because of it,
> > > > > > for example.
> > > > > 
> > > > > Asking systemd folks to change their development process because of
> > > > > limitations in Fedora/Koji seems like a big ask, don't you think?
> > > > 
> > > > Honestly, that never factors in for me, because then I'd never ask
> > > > anything of anyone. :)
> > > > 
> > > > But no, it doesn't sound unreasonable to me, because I reasonably
> > > > expect the parts that make up the EFI boot manager code to be somewhat
> > > > separate from the rest of the codebase in the first place. It targets
> > > > a different build environment and has to be built differently from the
> > > > rest of systemd anyway. So to me, it's not a "big ask" as you put it.
> > > 
> > > Once more (this has already been written *independently* by Lennart
> > > and me, but let's say it once again): THE USERSPACE AND EFI-SPACE
> > > PARTS SHARE CODE, the configuration system and the build system. So if
> > > we split them, we'd probably want to update them in tandem anyway, and
> > > it's just easier to do it, then to try to figure out if the sd-boot parts
> > > didn't change and we can skip the update.
> > > 
> > 
> > Yes, well he was asking me why I bothered to ask, and I answered. That
> > doesn't have a bearing on what reality turned out to be.
> > 
> > > Since the signing is automatic once configured, I can't grok what
> > > savings people foresee by doing separate builds.
> > > 
> > 
> > That's the point: correct signing is *not* automatic. It's *manual*
> > and done by *you* doing the build. Automatic signing is independent of
> > who does it, this is not that.
> > 
> 
> Another option that preserves the single source tree thing and
> probably will make Lennart happy is splitting this process in two:
> 1. systemd keeps building systemd-boot, but it gets split out as a
> subpackage (systemd-boot-unsigned-%efi_arch as noarch)
> 2. A new systemd-boot-signed source package BRs all
> systemd-boot-unsigned-$EFIARCH packages and signs them. It then
> produces "systemd-boot-$EFIARCH" subpackages that are signed that
> people can use.
> 
> That second package gets specifically marked to not get autobuilt,
> doesn't have a disttag, and basically goes through the entire
> exception path that shim uses today.
> 
> I think this matches what Michael Biebl was talking about for Debian
> that died on the vine.

Yes, this is how the EFI signing process was implemented for all
relevant Debian packages (not just for the sd-boot PoC), in order to
work with the, er, clunky infrastructure we have. More details can be
found here:

https://wiki.debian.org/SecureBoot/Discussion

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220427/b6a926ed/attachment.sig>