Re: UEFI Secure Boot sprint report

[Tollef Fog Heen <tfheen@err.no>]

]] Hideki Yamane 

> Hi,
> 
> > In the end, we decided to have a signing service which will construct
> > a source package based on a "template" package and a list of files to
> > sign and upload this to be processed by the normal buildd and dak
> > processes. The signing service will also have an audit log which makes
> > it public what was signed and when.
> 
>  I'm curious how this works.
> 
>  * source package was modified to generate <package>-$ARCH-signed-template
>    binary package
>  * dput it to repo and dak would pass to code sign service?
>  * sign binary package??

The signing service is a source package builder.

I'll use linux as an example package.  It's uploaded to experimental and
builds the normal set of linux-image-* packages.  In addition, it builds
a package named linux-image-amd64-signed-template.  This matches a
filter on the dak side, so it is exposed in
https://incoming.debian.org/debian-buildd/project/external-signatures/requests.json
(+ .gpg for the signature) as «this needs to be signed».

The signing service polls that URL regularly, and when there is a new
package available, it is downloaded and unpacked into a temporary
directory.  It includes a manifest of what files from what packages need
to be signed.  Those packages are downloaded, the files in the manifest
are signed and the source package is built, signed and uploaded, to be
built by the regular buildds.

This allows us to both keep the key in a central place, having
reproducible builds, having an automated process and not having to
execute any code from the template package as part of the build.

I hope this explains it well enough, let me know if there's anything
unclear, I'm happy to explain further.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are