On Sat, Apr 01, 2000 at 10:48:54PM +0200, Marcus Brinkmann wrote:
> No. Currently there is NO chain of verification (I should not have said
> "trust", it's the wrong term. Sorry).
So you agree that it would be an improvement?
> However, it doesn't establish a complete chain of verification from the
> developers to the users, au contraire to what you seem to believe.
Please don't tell me what I believe. I know that the solution is not perfect.
But it's way better then what we have now.
> > > 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.
> >
> > There is a difference between our master server trusting the uploaded
> > changes files. master will by definition always have the current keyring.
> > The user might not.
>
> Yes, but this doesn't change the point. The problem of out of date keys is a
> known problem in any public key cryptosystem.
That it is a known problem does not change anything. It still IS a problem.
While a developer might leave the project or even get thrown out the single
dinstall key would by definition last until either Debian dies (hopefully
this will not happen during my lifetime) or the key is compromised. In the
latter case you can expect that all Linux news services will pick up it
very soon.
> > Okay - signing Packages will make Debian as secure as master is. Fine.
> > We must assume that master is secure otherwise we are doomed anyway.
>
> Wrong. If you have signed debs, and you are careful when updating the
> debian-keyring package, there is no risk even if master is compromised.
I made two points. Which is wrong? I don't think my first point is wrong.
Signing packages will make Debian as secure as master is.
The second point might or might not be wrong. Currently what happens if
master is cracked? Right, we have a BIG problem. With the signed Packages
file we still have a problem in that and only that case.
But under the current setup we also have problem if our mirrors are cracked.
It might even be possible to crack a few push primary mirrors and everybody
will get a compromised Debian. We have to avoid this.
> This is the Debian way, right? Fetching the stick at the wrong end first.
> (Yes, this is a troll).
No. The Debian problem is searching the optimal solution for too long and
doing nothing in the meantime. We still have no perfect solution to improve
our release cycles. So we did nothing. potato is not perfect so we don't
release it.
I wonder why you are working for the Hurd project then? You can't even
run X11 Servers on the Hurd so why bother about it? The Linux kernel did
not much when it was first released - but it did something. And you can
improve it.
What I have to admit is that I tend to make the same mistake. Remember, I
wanted to fix GTK+ for the Hurd to not rely on MAXPATHLEN. There is an
easy work around to make it work but I wanted to essentially rewrite the
file selector.
I still did not have the time to finish that while having a working (okay,
working most of the time, it might fail with paths >4k) solution now would
be better I think.
Please stop retarding the efforts of other people because you think it is
not perfect. Get on with your work and let Anthony and Jason implement
the signed Packages.gz.
Thanks
Torsten
PS: Did I say I will leave the project if we don't implement the signed
Packages.gz? ;-))
--
Torsten Landschoff Bluehorn@IRC <torsten@debian.org>
Debian Developer and Quality Assurance Committee Member
Attachment:
pgpGVC4mwDWhq.pgp
Description: PGP signature