Using a signed shimx64.efi built by Arch Linux ---------------------------------------------- It is possible to build shim yourself and get it signed by Microsoft. [...] [I]t is possible to embed the public key of a certificate into the shim binary [...].> This certificate can be used to sign the boot loader and kernel so
completely automated out of the box, without having to enrol hashes. I think the best solution here is to use detached signatures and a separate package for the signed binaries, which builds the unsigned binary as usual, then attaches the signature (which can be distributed
On the bug tracker there was a question regarding the access to the secret key and the reproducibility of packages containing signed binaries. This concerns the second approach I suggested, i.e. that Secure Boot works publicly, unlike the secret key) and checks whether this results in a valid signed binary. Example ------- Consider the systemd-boot boot loader: the systemd package would stay unmodified and is used to build the unsigned EFI binary "systemd-bootx64.efi". To distribute a signed binary "systemd-bootx64.efi.signed", a person holding the secret key to the signing certificate would extract the binary and sign it by using a script along the following lines: tar -s '|.*/||' -xf systemd-*-x86_64.pkg.tar.xz \ usr/lib/systemd/boot/efi/systemd-bootx64.efi sbsign --cert pub.crt --key priv.key --detached systemd-bootx64.efi This creates a signature file "systemd-bootx64.efi.pk7", which isn't very useful on its own, but can be used to build a package "systemd-boot-signed" that contains a complete signed binary: The PKGBUILD of this new package is mostly the same as the existing systemd package, except for the following modifications: the public part of the signing certificate "pub.crt" and the signature "systemd-bootx64.efi.pk7" are added to the sources array (and to the public repository), and the build functions are adjusted as follows: build(){ # [...] usual build function here # sign the binary with the provided signature sbattach --attach "$srcdir/systemd-bootx64.efi.pk7" \ build/src/boot/efi/systemd-bootx64.efi } check() { # [...] usual check function here # verify that the signature is valid sbverify --cert pub.crt build/src/boot/efi/systemd-bootx64.efi } package() { # distribute only the signed binary install -Dm755 build/src/boot/efi/systemd-bootx64.efi \ "$pkgdir/usr/lib/boot/efi/systemd-bootx64.efi.signed" } Evaluation ---------- This has the following advantages: + Since the original package is not modified, users wanting to use the unsigned binaries (e.g. because they rebuild the package with local modifications) aren't affected at all. + Building the main and the signed package can be split between different developers/TUs, i.e. the maintainer of the original package does not necessarily need to have access to the signing key. + The amount of purely binary content (i.e. the signature) is kept to the absolutely necessary minimum. + It is possible for anybody to independently build and verify the signed package, check() will fail if the signature does not match the built binary. Disadvantage: - The PKGBUILD code is duplicated between the two packages. (Obviously, it would be easy to script the necessary changes to the signed package to minimise human error.) Alternatives ------------ Alternatives to this approach are: - Directly generating a signed binary by removing the "--detached" option from sbsign and distributing it as a binary package "systemd-boot-signed-bin". Avoids the PKGBUILD duplication, but makes it harder to verify that the signed binary is indeed the one built from source (but still doable by removing the signature with "sbattach --remove" and comparing the unsigned binaries). - Incorporating the assembly of the signature into the original PKGBUILD, e.g. by adding a makepkg option "--no-efi-sign" that skips all the signature stuff. You would then first build the unsigned binaries using this option, then you create the detached signature, add it to the sources and rerun with a normal "makepkg". This avoids the code duplication, but would probably require changes to makepkg because the currently available options don't seem to be a good match for this scenario.