-
Notifications
You must be signed in to change notification settings - Fork 312
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support offline signing #1759
Comments
I started working on this, my approach would be the following:
Question is: Do we defer creating the ESP until we have the signed UKI, or do we use mcopy to replace it? Am I missing something? My PR for ukify is here: systemd/systemd#33246 |
For my own reasons, I would like to add an additional file to the output partitions at the same time or before signing. Problem here is that adding this file needs to be done in a reduced cap environment (i.e. no unshare). |
I've thought a little about this, and I think that in this setup the signed UKI should come from a distribution package. Of course this means that the roothash can't be part of the cmdline anymore, which means that systemd/systemd#24027 will need to be solved first so that the roothash can be moved out of the kernel command line. Then the signed UKI and bootloader can be built ahead of time and installed as regular packages. mkosi can then learn to communicate the roothash to the user, which can then be signed offlline, and then we'll add a Note that this idea also depends on reproducible builds so that you can build once without |
Decoupling roothash from the cmdline definitely sounds elegant, so that the UKI does not have to be resigned for partition changes. I think in that case (for versioned image-based systems) the cmdline could specify data+verity+sig root partitions by label (instead of roothash), as long as systemd/systemd#24027 is not fully implemented. Only thing which is missing atm is the ability to specify the sig partition on the cmdline |
Currently signing (secureboot, verity) is done inline, ie: mkosi expects access to the private key material during the build. This doesn't work in many setups where the private key is kept on a detached system, accessible only through infrastructure-specific interfaces. The standard pattern there is to do the first build pass, get a list of hashes to sign, ship them off via some method, and get back detached signatures, and do a second build pass to apply such signatures. This is how OBS works for example: https://en.opensuse.org/openSUSE:Build_Service_Signer
So we'd need to support a build mode that creates the partitions and EFI images, but doesn't actually store signatures, and a second mode that takes a stubbed image and detached signatures, and applies them.
The text was updated successfully, but these errors were encountered: