Re: Bug#540215: Introduce dh_checksums
Russ Allbery <rra@debian.org> writes:
> Goswin von Brederlow <goswin-v-b@web.de> writes:
>
>> And what do you do when the archive key expires?
>
> Why would you need to do anything at all when the archive key expires?
> Keys don't become magically compromised or worthless just because they've
> expired. All it means is that you can't trust the integrity of really old
> signatures as much as you can trust the integrity of new ones.
s/expires/is compromised/
>> 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 see why. The only *.debs that we might need to resign are ones
> where there have been no uploads for an entire release cycle and hence may
> be released with expired signatures, and while there are a few of those,
> that's a much smaller problem. You could even just do an all-arch binNMU
> to deal with resigning those.
Packages are uploaded to unstable usualy and won't be signed by a stable
key at all. At most they get signed by the automatic archive key, which
is always in danger of being compromised. So on release every package
should be signed by the new stable key. Or at least all those that where
uploaded since the last release, which would be the majority.
>> 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.
>
> We could do that as well, but it would require changing the binary package
> format and the archive software to track an additional file, and I think
> that's a much larger change.
Changes files are alraedy archived. Just make them public.
>> 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.
>
> Multiple people have explained to you why this doesn't solve the problem:
> it means that you lose your signature path as soon as the package is no
> longer listed in Packages.
Which is why I kept writing the next paragraph.
> I'm not interested in new ways of authenticating packages that are still
> current and still listed in Packages. That's a solved problem, and while
> we can provide some moderate additional convenience, it's not really
> enough to justify the work. I'm interested in ways of authenticating
> packages that *aren't* listed in Packages, either because they're
> unofficial or because they're old and have been superseded. That would be
> a useful new feature.
>
>> 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.
>
> That's an interesting idea. Yes, we could add additional signatures to
> the *.changes file without any of this other impact. To solve the full
> problem for the Debian archive, we'd need to provide all the *.changes
> files for every *.deb that we've ever released, but thankfully they're
> small.
And exist for past debs as well.
MfG
Goswin
Reply to: