Bug#821051: Need support for uploading and signing EFI executables

[Ben Hutchings]

On Fri, 03 Aug 2018 21:49:19 +0800 Ben Hutchings  wrote:
> Control: retitle -1 ftp.debian.org: Get signing service running
> 
> At the Secure Boot sprint
>  a new
> architecture for code signing was agreed, and the implementation now
> exists at ;.
> 
> This bug should stay open until the signing service is in production.

The signing service is in production, with a production key.  However,
signing currently has to be approved manually, whereas in the long term
it's intended to be automatic.

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.




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

Bug#821051: Need support for uploading and signing EFI executables

[Ben Hutchings]

Control: retitle -1 ftp.debian.org: Get signing service running

At the Secure Boot sprint
 a new
architecture for code signing was agreed, and the implementation now
exists at .

This bug should stay open until the signing service is in production.

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.


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

Bug#821051: Need support for uploading and signing EFI executables

[Helen Koike]

On 2016-10-18 07:34 PM, Ansgar Burchardt wrote:

Ben Hutchings writes:

On Tue, 2016-10-18 at 22:55 +0200, Ansgar Burchardt wrote:

Is there any documentation how this is supposed to work?


Nothing comprehensive as yet.  Where should it go?


It doesn't need to be comprehensive.  I just would like to understand
what needs to happen.


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.)


How does building signed binaries work? That sounds like the signature
gets merged into the binaries dak signed in some way?


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?


Wouldn't the maintainer need access to the embargoed binaries as well as
the signatures to prepare the signed version?



As we briefly discussed on irc, we could solve all this by making dak to 
publish the -signed packages automatically, is this a good solution? 
Please, let me know your opinion so I can go ahead and implement a first 
version of it.


Thanks
Helen Koike

Bug#821051: Need support for uploading and signing EFI executables

[Ben Hutchings]

On Tue, 2016-10-18 at 23:34 +0200, Ansgar Burchardt wrote:
> Ben Hutchings writes:
> > On Tue, 2016-10-18 at 22:55 +0200, Ansgar Burchardt wrote:
> > > Is there any documentation how this is supposed to work?
> > 
> > 
> > Nothing comprehensive as yet.  Where should it go?
> 
> 
> It doesn't need to be comprehensive.  I just would like to understand
> what needs to happen.
[...]

In brief:

1. A first source package (grub, linux, etc.) builds byhand tarballs
containing all the files that need signing, in addition to the usual
binary packages.

2. The byhand script on dak unpacks the tarball, generates detached
signatures using the appropriate key(s) and publishes another tarball
containing those signatures.

3. The maintainer prepares a second source package (grub-signed, linux-
signed, etc.) containing the detached signatures.  It build-depends on
the unsigned binary packages produces by the first source package, and
builds signed binary packages based on them.

I hope that answers all your questions.

Ben.

-- 
Ben Hutchings
To err is human; to really foul things up requires a computer.

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

Bug#821051: Need support for uploading and signing EFI executables

[Julien Cristau]

On Tue, Oct 18, 2016 at 22:55:19 +0200, Ansgar Burchardt wrote:

> Is there a way to not pass the pin via command-line arguments as
> currently implemented in [1]?
> 
Linux's sign-file, which is used for kernel modules, reads the
KBUILD_SIGN_PIN environment variable.

Cheers,
Julien

Bug#821051: Need support for uploading and signing EFI executables

[Ansgar Burchardt]

Ben Hutchings writes:
> On Tue, 2016-10-18 at 22:55 +0200, Ansgar Burchardt wrote:
>> Is there any documentation how this is supposed to work?
>
> Nothing comprehensive as yet.  Where should it go?

It doesn't need to be comprehensive.  I just would like to understand
what needs to happen.

>> 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.)

How does building signed binaries work? That sounds like the signature
gets merged into the binaries dak signed in some way?

>> 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?

Wouldn't the maintainer need access to the embargoed binaries as well as
the signatures to prepare the signed version?

Ansgar

Bug#821051: Need support for uploading and signing EFI executables

[Ben Hutchings]

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] 
> 
-- 
Ben Hutchings
To err is human; to really foul things up requires a computer.



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

Bug#821051: Need support for uploading and signing EFI executables

[Ansgar Burchardt]

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?

Which files do need to be signed? And by what key?

What uses the signatures the archive is planned to write to dists/*?

It looks wrong to bypass embargoed for the signatures. We avoid showing
which packages will get security updates in the future.

Is there a way to not pass the pin via command-line arguments as
currently implemented in [1]?

Ansgar

  [1] 

Bug#821051: Need support for uploading and signing EFI executables

[Steve McIntyre]

Package: ftp.debian.org
Control: block 820036 with -1

Hi folks,

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.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess