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

Re: Signing Packages.gz



On Mon, Apr 03, 2000 at 12:10:27PM +0200, Marcus Brinkmann wrote:
> > We might want to revoke the old key. If James leaves we can't revoke his key
> > because it is HIS key. We can however revoke the dinstall key because it 
> > is by definition Debian's key. But this is nitpicking.
> Who is Debian?

Look around you. Look in a mirror even. You know the answer to this.

> Where is the safe where the secret key will be stored
> (as the keys from Microsoft are)? Who will be responsible for all this, and
> what makes you belief that those will be more careful about the key
> than James?

master.debian.org; debian-admin and the ftp people; and mu. We've been over
this.

> The central authority doesn't mix extremely well with the distributed
> organization Debian is.

This isn't a central authority, and it does actually mix well with Debian.
It doesn't create a choke point, it's easy to implement, it doesn't add
any authority to anyone, or extra control to anyone.

This argument, coming from you, actually makes a hell of a lot more
sense to me than some of the others made in this thread. But I don't
*think* it's actually a problem: it formalises the group yes, which can
definitely be dangerous, but it doesn't centralise it, or distort it,
or restrict it, or anything, as far as I can see. (This is in contrast
to the constitution, eg, which does centralise some things, and does
distort others. General resolutions are a distortion of the regular
cut-and-thrust of consensus building, eg)

> > You have started the child game. We want to make a simple change to apt as
> > dinstall and you keep telling us that it won't make things better. Now you
> > said that making things better but not perfect is not the Debian way of 
> > doing things.
> Yes. Because the Debian installation tool is dpkg, and not apt.

dinstall is a part of dpkg, and Apt is now the main dinstall method. That
makes apt pretty central to Debian. That's the first point.

The second point is that signed Packages are incredibly easy to verify
manually. You run ``gunzip Packages.gz; gpg --verify Packages.gpg
Packages''

ie, people who don't want to use apt can quite happily make use of these
signatures, in their favourite dselect method.

If you want to verify a particular package, you can (hypothetically) do:

	gunzip Packages.gz
	gpg --verify Packages.gpg Packages
	# check to see that it's signed by the right key, as well as
	# that it's a valid signature
	MD5a=`grep-dctrl -F 'Package' -s MD5sum '^telnetd' Packages |
		 cut -d\  -f2`
	MD5b=`md5sum telnetd.deb | cut -d\  -f1`
	if [ "$MD5a" = "$MD5b" ]; then
		echo "MD5sum match"
	else
		echo "MD5sum mismatch :("
	fi

As far as ease-of-use and good-use-of-bandwidth-and-time go, I think
signing Packages.gz is optimising for the right case (ie the common one).

> This is the second main point that I disagree with (aside of the security
> discussion, which is complicated and by now covered well). A solution
> for Debian should serve all people, those who use apt, those who use dpkg
> and downloaded files, those who use other methods (dselect etc).

Is this satisfied too, now, then? Well, perhaps not satisfied, but at
least somewhat alleviated? (For people who download by hand and just
use dpkg, clearly dpkg --check-deb-sig is obviously much more convenient)

Cheers,
aj

-- 
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: pgpWlz1EtUEWh.pgp
Description: PGP signature


Reply to: