On Wed, 2022-04-27 at 13:31 -0400, Neal Gompa wrote: > On Wed, Apr 27, 2022 at 1:07 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > On Wed, Apr 27, 2022 at 12:19 PM Zbigniew Jędrzejewski-Szmek > > <zbyszek@xxxxxxxxx> 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@xxxxxxxxxxxxx> wrote: > > > > > > > > > > On Wed, Apr 27, 2022 at 9:10 AM Neal Gompa <ngompa13@xxxxxxxxx> 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
Attachment:
signature.asc
Description: This is a digitally signed message part
