[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Signing Packages.gz

On Fri, Mar 31, 2000 at 08:22:14PM -0700, Jason Gunthorpe wrote:
> 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.

Just about everything is prone to the hack-a-mirror thing at the very
first point. If you hack-a-mirror and change James' key in debian-keyring,
and no one has a copy of debian-keyring already do compare it against,
you're stuck.

The dinstall key could be verified by:

	* the web of trust, and having the ftp-team sign it

	* putting a fingerprint on the website and in Debian books,
	  and making it easy for people to verify said fingerprint

	* getting copies of the key from multiple sites, and checking that
	  all the copies you got are the same

None of these are completely foolproof, of course.

> 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. 

This key (or the private half thereof) wouldn't need to be anywhere near
any public machines, either.

> The trick however is to distribute the security key automatically and
> efficiently. [The dinstall key can be derived from this one] Ponder
> Ponder. 

Stick it on the ftp site, and use the web of trust. (If the secure-key that
you currently have trusts it, then it's good. Either because it's an update
of the old secure-key, or because it's an unstable-key).

`Using' the web of trust is probably easier said than done, though.

> Incidently the dinstall change is all of (basically)
> cd .../dists/unstable/
> find -name "Packages" -or "Packages.gz" | xargs mymd5sum | gpg --clearsign > Packages.sig

I'd have done:

  find -name Packages -o -name Sources -exec gpg --detach-sign --armor {} \
     -o {}.gpg

or so before gzipping anything.

> APT would need to download this file, verify, then load the md5s
> internally for checking the package files.

I'd have made it download a Packages.gpg as well as Packages.gz and
Release, and if:

	(a) Apt::Require-Gpg=true (or something) and: gpg isn't installed,
	    or the unstable key/security key doesn't exist, or
	    Packages.gpg doesn't exist

or 	(b) The .gpg isn't a signature of the Packages file by one of the
	    proper security or unstable keys

then die horribly.

Updating the key would need to be a completely separate operation to
downloading packages (it'd have to be done first, in case the keys
outdated, and it'd have to be verified differently).

Or at least, that's how I was toying with doing it a while ago, and
apart from not knowing how to make an Apt option, or wanting to do a
system call properly and elegantly (as opposed to using system()) it
was working fairly well.


Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds

Attachment: pgp6quTw1ZzOX.pgp
Description: PGP signature

Reply to: