Re: Bug#540215: Introduce dh_checksums
On Wed, Mar 17, 2010 at 02:36:31PM +0000, Simon McVittie wrote:
> 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!).
Thanks for explaining all these details.
> 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.
Theoretically you could produce rather short-lived keys that are
signed with your maintainer key, make those available in the build
environment and use them for signing. The signing key along with the
signature by the maintainer key would have to be included in the
package as well. But I guess that this would be a tad to complex and I
wouldn't propose it.
harry
Reply to: