On Wed, 2016-08-03 at 18:44 +0200, Julien Cristau wrote: > Hi Ben, > > On Thu, Jun 30, 2016 at 21:31:06 +0100, Ben Hutchings wrote: > > > > > It takes a tarball of code objects and generates a tarball of > > corresponding detached PKCS#7 signatures (with '.sig' suffixes). > > > > It will sign: > > - EFI binaries (*.efi, vmlinuz-*) using pesign > > - Linux kernel modules (*.ko) using sign-file from linux-kbuild-<version> > > > > Currently it should work with private key files and certificates. It > > may be able to sign kernel modules with a key on a PKCS#11 device. > > It definitely can't sign EFI binaries using a PKCS#11 device yet. > > --- > > scripts/debian/byhand-code-sign | 148 ++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 148 insertions(+) > > create mode 100755 scripts/debian/byhand-code-sign > > > So this takes foo.tar.xz from a package upload, signs all the files, and > makes a tarball of signatures exported as > /dists/<SUITE>/main/code-sign/foo_signed.tar.xz. "foo" is supposed to > be <PACKAGE>_<VERSION>_<ARCH>, but I didn't see anything actually > checking that, so could two packages stomp on each other? As I understand it, the <PACKAGE> part has to match one of the section names in the dak config under AutomaticByHandPackages and the source package has to match the source package specified in that section. So that should prevent collisions between packages. There's nothing that enforces the presence of _<VERSION>_<ARCH>, except that if there are any underscores in the filename there must be exactly two. In fact dak completely ignores the <VERSION> - it passes a version string to the byhand script, but it's the source package version. So each source package gets to manage its own namespace. > For comparison, as far as I can tell ubuntu expects the tarball to be > named package_version_arch.tar.gz, and the signatures are exported in > /dists/<SUITE>/main/signed/<PACKAGE>-<ARCH>/<VERSION>/signed.tar.gz. > They don't seem to use detached signatures, though (and seem to have > added kernel module signing to their sbsigntool package). Exporting signed binaries would either result in breaking embargoes or result in the security team having to do source uploads for the signed packages. But creating subdirectories seems reasonable. > And I don't > know if they validate that package/arch/version tuple against the > upload. > > Should we somehow add these files to the db, so they can be cleaned up > when the corresponding source package goes away? I guess these won't > be too big, and there's precedent with things like > http://ftp.debian.org/debian/dists/sid/main/installer-amd64/ so maybe > this isn't a concern at least initially. I was thinking that they could be removed by a cron job. The signatures should always be downloaded and used within a few days, so deleting all code-sign tarballs older than 30 days would be reasonable. Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure.
Attachment:
signature.asc
Description: This is a digitally signed message part