On Thu, Apr 08, 2004 at 02:55:59PM -0500, kfogel@collab.net wrote:
> Okay. My feeling, after reading the whole thread, is that we should
>
> a) Forget about the shared key for now.
>
> b) Make sure that three or four developers sign each release.
>
> c) Make an effort to get all developer's keys into well-connected
> trust networks (pretty easy, considering that we have a high
> degree of personal contact/overlap with other projects like
> Debian, Apache, etc).
>
> I hope Ben Reser will forgive me for (a), considering that I was in
> favor of a shared key before... Two things changed my mind:
>
> 1. It would have made the CollabNet developers "special" when it
> comes to releases. (Although this specialness wasn't a
> necessary property of the system, it would have been the path of
> least resistance for a while.)
>
> 2. It complexifies the whole system generally. Everyone's got
> their own ways to manage their personal keys. But with a shared
> key, we have to coordinate how to manage it.
>
> 3. While we *think* the shared key would be easier for users, do we
> actually know this? IOW, premature optimization.
>
> So, how do people feel about this simplified version of Ben Reser's
> proposal?
I have to disagree 100%. The arguments so far against it IMHO have been
repeated talking points of "It's bad".
Here are the problems I see with the arguments against it:
1) Since the people presenting these arguments are comfortable with
GPG/PGP and the web of trust. They assume other users will be. I think
the whole web of trust thing is fundamentally confusing to end users in
general. If you don't believe me go look for all the FAQs about it.
It's not easy to explain, understand or use.
2) They assume there is no shared trust. But is is flat out wrong.
When I download and use Apache, I'm not trusting the individual
devleopers. I'm trusting the ASF and the various contributors. It's
based upon the belief that there are checks and balances and that while
I can't necessarily trust an individual developer that I don't know, I
can trust the group due to their track record and the process they have
in place.
Trying to express that shared trust with only individual developers keys
is IMHO a serious mistake.
Since we all reasonably "know" each other it's much easier to see things
as trusting individuals. But our users don't know individuals. They
know a project name.
3) They claim that shared keys are bad. And they're right in an ideal
perfect world. But in an ideal perfect world a lot of security models
that are just downright unusable in the real world can exist.
Fact is we deal with shared keys every single day. The biggest and most
widely deployed instance of this is the entire SSL/TLS infrastructure.
Certificates are signed by shared keys, e.g. the certifying authorities
key. There is no individual name attached to that key. It's not even
attached to a specific domain name. We actually have to trust out of
faith that it truly belongs to the certifying authority and that they
are taking their best efforts to only use it apropriatly and securely.
4) Doing a shared key and individual signatures doesn't disallow people
who don't trust or like shared keys from authenticating with only
individual keys. Not doing the shared key just increases the work
required for a user to use this authentication method. Meaning users
who don't have a path to any of the developers who signed the release
will end up falling back on the md5sum.
Additionally, individual keys mean a user might have a trust path for
one release and not another one depending upon who signs the releases.
5) I don't think it makes the CollabNet people special. It's just
simply easiest to deal with right now until people can get together in
person. I know I'll be in Chicago this summer, probably sometime in
June.
But further, the shared key is being signed after individual developers
have signed. All this means is the CollabNet people are doing some
grunt work. It doesn't make their "vote" any more important. They have
equal say in deciding if that key's signature gets applied or not.
If people are paranoid about the CollabNet people trying to exclude
people or putting their interests first then we have a whole lot of
other issues to fix. Everything is hosted at CollabNet.
6) It doesn't complicate things. It only complicates things if the
people who dislike shared keys try to push their views onto the shared
key.
I think the requirements they try to put on the shared key really aren't
necessary. We can do them if we really want to be that paranoid, but I
think they're unnecessary. Frankly, I'd let the people who can upload
releases have access to this key. Provided it was given to them in
person.
Again nobody is forced to use this shared key. It's an option to the
end users.
So if we're voting on this I'd vote -1 (not a veto).
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 9 07:05:19 2004