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.


> Ansgar
> >   [1] <https://bugs.debian.org/821051#82>
Ben Hutchings
To err is human; to really foul things up requires a computer.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to