[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#821051: [PATCH 1/3] Add byhand script to perform code signing

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

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.


Reply to: