Re: Bug#540215: Introduce dh_checksums
On Wed, 17 Mar 2010 at 12:41:58 +0100, Harald Braumann wrote:
> It should be signed at build time, just after dh_shasums and then the
> sig file packaged together with all the other files. I don't see a
> problem with that. Or maybe I'm not getting something here?
Most packages (in terms of proportion of the archive, in particular for
architectures other than i386 and amd64) are built by a buildd, so each buildd
would have to have a signing key that could sign the checksums file during
build. Further, the build part of a buildd runs inside a limited chroot
running the target distribution, i.e. usually unstable (the "real system" runs
stable with a backported version of sbuild), which doesn't have access to any
key material in the "real system".
At the moment buildds don't have their own keys: a buildd maintainer inspects
the build log and signs the .changes file for upload.
Even for maintainer uploads, maintainers who build their packages in a
minimal chroot with schroot, pbuilder, cowbuilder etc. (which is strongly
recommended) don't necessarily have their signing key available inside
the chroot (nor should they!).
I build my packages with sbuild/schroot, and my GPG key isn't available inside
the build system as a result of using gfcombinefs to split my key between my
laptop and a USB stick (so that if either is stolen, my key isn't compromised).
I'm told some developers take this further, and only store their key on a
non-networked machine to which they transfer files for signing (the current
package upload procedure makes this possible - they only really need to
transfer the .changes file, in fact). I think it would be irresponsible to
make it necessary for DDs to choose between weakening the security of their
GPG keys, or producing less reproducible builds.
Another issue with signing automatically at build-time is that it gives
preliminary versions of a package the same level of authentication (signature)
as the uploaded version. It sometimes takes a few iterations to make a final
build of a package, so the workflow I use is to build an unsigned package and
test it. If it works well enough to be suitable for upload, I sign and upload
it; if it doesn't, I discard it, amend the source and repeat.
Simon
Reply to: