Re: Bug#540215: Introduce dh_checksums
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? 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.
MfG
Goswin
Reply to: