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? 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). 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. Cheers, Julien
