Re: Signing Packages.gz
On Sat, 1 Apr 2000, Anthony Towns wrote:
> I'm not sure why this isn't getting through. Automatically, cavalierly
> signing Packages.gz on master *HAS DEFINITE GAINS OVER THE PRESENT WAY
> OF DOING THINGS*.
How exactly do you propose to transfer a verification key to the clients?
I can't think of any decent way to do this that isn't prone to some kind
of hack-a-mirror thing or involves annoying extra steps.
You are wrong about signed .debs vs signed package files. Signed .debs are
not worth the bytes to transfer a signature and the time check it. Their
only real use is to check the master archive against hack/corruption and
even that is better served by saving the uploading .changes file
[preferably on multiple hosts, hence d-devel-changes]. In fact I would
argue .deb sigs only give people a false sense of security because it
makes the system as weak as the weakest key in our keyring.
Signed package files on the other hand provide a really fast and efficient
way to definately verify the whole chain, from us to the user. In
particular, we could have a relatively insecure daily use dinstall key
[for unstable] and a strong release key (aka the key the security team
uses) When we do a release all the package files are signed using the
security key and we have a nice sealed package that can be checked quickly
and efficiently by the users.
The trick however is to distribute the security key automatically and
efficiently. [The dinstall key can be derived from this one] Ponder
Ponder.
Incidently the dinstall change is all of (basically)
cd .../dists/unstable/
find -name "Packages" -or "Packages.gz" | xargs mymd5sum | gpg --clearsign > Packages.sig
stable would be signed once at each release time by the security team.
APT would need to download this file, verify, then load the md5s
internally for checking the package files. It would also have the nice
side effect of providing accurate progress meters for package files
(since you would want to include sizes in the index.).
There are some tricky details about how to locate the .sig file for each
package file, but that I think is fairly resolvable..
Jason
Reply to: