On Tue, 2016-10-18 at 22:55 +0200, Ansgar Burchardt wrote: > Steve McIntyre writes: > > As discussed with various people in the past, for UEFI Secure Boot to > > work we'll need changes in dak (and elsewhere?) to support upload and > > signing of EFI executables. > > > > Colin has pointed at the code in launchpad as inspiration: > > > > https://git.launchpad.net/launchpad/tree/lib/lp/archivepublisher/uefi.py > > https://git.launchpad.net/launchpad/tree/lib/lp/archivepublisher/tests/test_uefi.py > > > > We'd love to make this happen in time for stretch if at all possible. > > > Is there any documentation how this is supposed to work?
Nothing comprehensive as yet. Where should it go? > Which files do need to be signed? And by what key? EFI binaries and kernel modules. EFI binaries need to be signed by a key for which the certificate is embedded in shim, and kernel modules need to be signed by a key for which the certificate is embedded in linux. There is no need for those keys to be the same as each other. > What uses the signatures the archive is planned to write to dists/*? Scripts for preparing the source packages that build signed binaries. (Which will probably be included in those source packages, but don't have to be.) > It looks wrong to bypass embargoed for the signatures. We avoid showing > which packages will get security updates in the future. That's a fair point. But they need to be findable by a maintainer who doesn't have access to embargoed packages in general. How about using a hash of the changelog? > Is there a way to not pass the pin via command-line arguments as > currently implemented in [1]? I don't know the answer to this. Ben. > Ansgar > > > [1] <https://bugs.debian.org/821051#82> > -- Ben Hutchings To err is human; to really foul things up requires a computer.
signature.asc
Description: This is a digitally signed message part
