Source: shim Version: 15+1533136590.3beb971-2 Severity: normal X-Debbugs-CC: debian-efi@lists.debian.org Dear Mantainer, As requested on debian-efi, opening a bug trying to collate all information and rationale with regards to using the Debian key to sign MoK and FB. The debian-efi developers and collaborators, as discussed during the secure boot sprint [1], would like the things we (Debian) sign to be reproducible so anybody can make sure that nobody (including Debian) sneaked in any changes. Albeit the shim binary gets signed by Microsoft (and not by Debian) the same logic should apply to it: We want to make sure that nothing got changed in shim by anybody. Although a run of diffoscope would show that the only things changing are the ephemeral embedded key (and the host kernel version), this is a manual step that would not be easily accessible to non-tech-savvy users. Having reproducibility "just work" by default means that the CI can take care of it, and notice regressions automatically. The Debian key, other than for fwupdate, kernel image and GRUB, is already used to also sign all the Linux kernel modules, which are ~3.4k for linux-image-4.9.0-8-amd64, multiplied by our number of architectures and sub-architectures. So, using it for MoK and FB as well doesn't seem to add much more exposure, in the grand scheme of things. The work to make src:shim use the Debian signing infrastructure was already done last year by Philipp, and is available on Salsa [2]. In case it can help to share the workload, I will try to do some work later today to cherry-pick those commits and send an MR on Salsa for the latest version. Thank you for your work on Shim! -- Kind regards, Luca Boccassi [1] https://etherpad.wikimedia.org/p/debian-secure-boot-2018 [2] https://salsa.debian.org/pmhahn/shim
Attachment:
signature.asc
Description: This is a digitally signed message part