Re: Signing Packages.gz
- To: firstname.lastname@example.org
- Subject: Re: Signing Packages.gz
- From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
- Date: Sat, 1 Apr 2000 16:00:20 +0200
- Message-id: <20000401160020.E309@ulysses.dhis.net>
- In-reply-to: <20000401125553.B25544@azure.humbug.org.au>; from email@example.com on Sat, Apr 01, 2000 at 12:55:53PM +1000
- References: <20000324124741.F30466@foursquare.net> <firstname.lastname@example.org> <20000326090034.E9092@azure.humbug.org.au> <20000326160220.C454@ulysses.dhis.net> <20000327083710.A30185@azure.humbug.org.au> <20000401012403.A4090@ulysses.dhis.net> <20000401121501.A25544@azure.humbug.org.au> <20000401125553.B25544@azure.humbug.org.au>
On Sat, Apr 01, 2000 at 12:55:53PM +1000, Anthony Towns wrote:
> But unfortunately that's not quite the choice I have either, since for
> some reason that I can't fathom, people seem to think that a dinstall
> key would be an abomination to man and God and I'd probably be summarily
> kicked out of the project as soon as I tried sending a patch somewhere.
> Or at least it'd never get applied.
It seems you feel personally insulted. I am sorry for this, but
unfortunately it doesn't change the situation that the signed packages case
adds a further point of weakness to the chain of trust.
You are correct that both systems can be applied. Signing debs verifies that
a package comes from a (probably former, if keyring is out of date) developer.
Signing Packages verifies that the contained packages come from master.
As dinstall verifies the keys on the packages (which already exist, btw,
they are just not propagated), it puts itself in the middle of the chain:
signed packages --> dinstall --> user
We already use link 1 (signed changes files), and trust it. This won't
be changed by either proposal. Yes, even in the signed packages file you
trust all developers keys.
Now link 2. It is currently absent. What you seem to suggest is to add a key
(dinstall-key) here, so the user can verify the archive. This adds a point
of weakness. As the dinstall key can't be used automatically and kept "truly"
secret (it directly depends on the security of master), this weakness is rather
huge. This problem is avoided if the link 1 is propagated to the users:
signed packages --> dinstall
In this situation, I don't have to trust anyone except the Debian developer.
Not the admin team, not the security team, not master, not dinstall. Can't
you see that this is a crucial advantage?
If you also want a link 2 from dinstall to the user, I don't care. But don't
tell the users that link 2 asserts that all packages come from Debian
developers, it doesn't.
What link 2 asserts instead is that the packages come from master. It solves
the mirror problem, but does not solve the master problem.
I don't object to a signed Packages file, but it is important to see which
problem it solves and which it doesn't solve. Also it is important to
realize that the secret key automatically used by dinstall can not be stored
in a highly secure way.
 As secret as any PGP key should be kept.
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
Marcus.Brinkmann@ruhr-uni-bochum.de, email@example.com PGP Key ID 36E7CD09