Hi Marcus,
On Sun, Apr 02, 2000 at 02:32:04PM +0200, Marcus Brinkmann wrote:
> > No, the user cannot verify that. The user can check the signature against
> > our keyring but they have no idea who *should* have signed it.
>
> It seems to be hard to understand, so I will explain it one more time:
>
> Why do you think this is not true in the signed packages case? Because you
> only have one key to verify and trust, the dinstall key.
No, because the signatures on that packages are seen by Debian developers
following -devel-changes as well as by the ftp admins.
> In my case, there is also a single one key to trust: The key used to sign
> the debian-keyring package.
No, you also have to trust the maintainer who signed the package. There is
no way for an end user to know how is maintaining a package without
following -devel or somesuch or know if an NMU is okay.
> To complete the analogy: You could sign the debian-keyring package with your
> dinstall secret key to reach the same effect. Only that we alread have a
> debian-keyring package, and no mechanism to sign Packages files.
We don't? Ever tried gpg -a --clearsign Packages.gz?
> The signature on the Packages files corresponds the signature on the
> debian-keyrng package in some way. Both secret keys should be kept private,
> but it is easier with the latter, as it is a trusted maintainers package.
Why does that make keeping the key private easier?
> If this ever changes, we need to publish a different public key to verify
> against, the same is true for the dinstall key.
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.
> > This is aside from the other problem of keeping 600 keys up to date on the
> > client machines and making sure that huge keyring is not disturbed in
> > transit.
>
> Oh yeah. I think if you are paranoid, you don't care about 500k additional
> bandwidth. Can you be more specific about the "disturbed"? I don't know of
> any valid attack that involves "disturbing the transit"?
Break into a mirror and modify the debian-keyring package. For new installs
this will be enough to break into a system.
> BTW, just to turn it around for the sake of argument: The Packages file is
> bigger than the debian-keyring.
But you always need the Packages file anyway (if you are using apt that is).
> > If we store the .changes files as I propose then the end use can check it,
> > if they want.
>
> Yes, and it should be stored, and verificable automatically.
Please tell me then how to verify the debian-keyring package?
> > But nobody will, because it is not a usefull thing to check.
>
> You say so. I disagree, and I think I gave sufficient arguments to show the
> opposite. Unfortunately, the people involved in this discussion are not
> interested in working out a good solution, but to win an argument. I don't
> have time for child games, sorry.
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.
I have to say I am glad that not all developers think this way. Otherwise we
would still be discussing on debian-admintool how to implement a configuration
manager. Did you notice that debconf was not perfect at first? It is still
not perfect (my opinion) but it is working. And it is better than nothing.
Regarding the argument: I do not care if we win this argument. If I'd be
the project leader I would say let's just ignore you and implement what
we are discussing. It would take much less time to do so instead of talking
to a brick.
Question is: Who can decide if we implement this? Jason? Richard? Manoj?
Wichert? Why are we discussing this all the time anyway?
> The signed deb case not only has all the advantages of the signed packages
> file (there is almost a one to one correspondency, modulo location of the
> secret key (dinstall/debian-keyring)), it also allows verification of
> individual packages from a different source, which does not come with a
> packages file.
Cool. We want this key to prove that the package actually originates from
Debian and you are telling us it is better if it can come from somewhere
else?
> It seems that people around here are happily throwing away an integrated
> solution in favour of a simple one. I doubt that the dinstall key will be
> stored secretly, and I doubt that the responsible people will tell the
> truth about this. This will lead to a false security by the user, and this
> is what I am concerned about.
We are not telling our users currently how insecure Debian is. RedHat did
have the single key from the start. You can verify RPMs. Tell them it's
more insecure that what Debian has.
Currently we have no security at all. Breaking into ftp.random.debian.org
will suffice.
> > It has use to definitively verify the root archive (say, after a hacking
> > or something) but otherwise the end user cannot make much use of it at
> > all.
>
> The root of the packages are the developers, not master.
But they are distributed from master no matter where they originate. If I
gain root on master I can just put random.deb into the archive and it will
be copied to our mirrors. Correct me if I am wrong.
> > The dinstall and security keys (particularly the security key) are going
> > to be far, far more secure than the weekest key in the key ring.
>
> It's a single point of failure, while maintainer keys only are applied to
> some packages.
Where is your point? If you break the chain you break the chain. It does not
matter if you break every element of the chain or only a single one.
> > This is a flawed assertion - by your logic SSL is insecure and must not be
> > used. In reality it is a perfectly good system that has really good
> > security benifits.
>
> I don't know SSL, so, no comment. It does however serve a different purpose
> (encryption of streams, as opposed to verification of archives), so I doubt
> whatever is true for SSL is applicable to this discussion.
SSL is used to ensure you are sending data to the right machine and getting
data from the right machine. Say you are talking to amazon.de with SSL
this tells you you got the right machine. So you can submit your credit
card information and the prices they show are serious.
It has the same point of failure of course - if somebody breaks into the
machine he can act as that machine because it has the private key on it.
cu
Torsten
--
Torsten Landschoff Bluehorn@IRC <torsten@debian.org>
Debian Developer and Quality Assurance Committee Member
Attachment:
pgpqLmEHnsIHx.pgp
Description: PGP signature