Re: Bug#540215: Introduce dh_checksums
On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote:
> Russ Allbery <rra@debian.org> writes:
>
> > 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?
>
> The changes files are afaik archived somewhere and are needed to verify
> the archive integrity after a (feared) compromise.
>
> And what do you do when the archive key expires? Resign every deb in the
> archive and have every mirror download them all again?
Why? A signature doesn't become invalid just because the key
expires, as long as the signature was created before the expiration of
the key.
> Same problem on
> releases. Releasing a new stable means a new stable key so every deb
> needs to be signed again and changes. I don't think this is a good idea.
> This would also cause users (apt/aptitude actually) to reinstall the
> packages needlessly creating even more mirror load.
>
> For this to work the signature for the checksum files should be detached
> so that it can be changed/extended without altering the deb files.
>
> I suggested this before but lets repeat it. Why not include a digest of
> the checksum file in DEBIAN/control, carry it into the changes file and
> into Packages.gz. That way all current debs automatically have a clear
> trust path.
>
> Further the changes files could be included in the pool alongside the
> debs and source files. That way everyone can verify the autenticity of
> the debs (or just the checksum file) independent of the archive
> key. Going one step further the changes files could be signed by the
> archive key(s) as well. Adding a new signature to them when keys change
> does mean they need to be mirrored again but they are relatively small.
Self-contained packages, where the signature is included and installed
along with the checksum file, would have a lot of
advantages. You wouldn't need access to a lot of infrastructure just
to verify a signature. It would be very simple. It could be used for
packages, that are not part of Debian. For instance, I could produce a
package and send it to a friend and he could later use my key for
verification. The same holds for projects that publish deb files. With
your proposal they would need a full fledged archive and keep a long
history of all the files.
And what do you do with packages from testing/unstable/experimental?
Would you keep all incarnations of the Release/Packages/changes files?
And if I want to verify the signature of an installed file, from a
package I once installed from, say, unstable, how would I find the
right version of the changes file for the package?
Cheers,
harry
Reply to: