Re: Bug#540215: Introduce dh_checksums
Simon McVittie <smcv@debian.org> writes:
> 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!).
Signatures per buildd or per DD doing uploads are moderately interesting,
but not nearly as interesting as a signature by a long-term stable key
such as the archive key.
Do we actually rely anywhere on packages not changing hashes between
upload and publication in the repository, or is it just something we have
as an invariant now because there's no reason for it not to be one? The
path of least resistance here would be for DAK to add the package
signature after verifying the signature of the uploader. This has the
drawback that it modifies the *.deb and therefore breaks the hashes in the
*.changes file and hence its original signature, but given that we throw
out the *.changes file anyway, do we actually care?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: