Re: Bug#540215: Introduce dh_checksums
Harald Braumann <harry@unheit.net> writes:
> 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.
You can always sign the deb. The tools to sign and verify are all
present. Only ftp-master stands in the way of using that.
And you could automatically download the changes files along with every
deb and keep all changes files for installed package/version
locally. Anyway, I don't consider a ftp/http client a lot of
infrastructure. It would be trivial to write a tool that downloads the
changes files for every installed package and verifies it.
> 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?
All changes files are already kept. And you would go directly to
fetching the changes file for the package/version you have
installed. All it would need is for the changes file archive to become
public.
> Cheers,
> harry
MfG
Goswin
Reply to: