Re: Bug#540215: Introduce dh_checksums
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.
> 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.
> 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.
> 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.
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.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: