On Fri, Apr 09, 2004 at 09:24:26AM -0500, kfogel@collab.net wrote:
> I think that's maybe not a useful way to approach this decision.
>
> We've had no signing policy for releases before this. Now we've got
> two proposals on the table, one of which is a strict superset of the
> other. The common portion of both proposals is: individual developers
> sign the release with their personal keys, and sign each others keys
> as much as possible. That part's a no-brainer -- we'll want to do it
> no matter what.
Sure I'm in favor of individually signing the packages. But frankly, I
think the individual signing is only useful for people who are involved
with the project and actually know who the various developers are. If I
had to pick one aspect to drop to make things simpler it would be the
individual signing. The majority of our users IMHO simply won't find
individual keys as useful.
> Then there's an extra bit, added for user-friendliness: have a shared
> project key that signs every release, no matter which particular
> developers were involved in the release. That way users can learn to
> trust that key and not have to worry about trust paths for subsequent
> releases.
>
> By saying "-1 (not a veto)", you seem to be indicating that you're
> against implementing the common portion of the proposals if we're not
> going to do the extra bit as well. But I doubt that's what you really
> mean. Surely you can't be suggesting that we shouldn't sign at all if
> we don't sign with a shared project key :-).
Yes and no. I see this as a bit like saying "Okay we're going to GPG
sign releases now so we don't need to post md5sums." There are two
ways to use GPG. Shared project keys and individual developer keys.
We've beat to death the benefits and negatives of both of these. I
presented what IMHO was a compromise, to do both. Then both camps can
use their preferred method. Nobody has come up with a reason why a
shared key is harmful to those that don't want to use it.
Individual keys let people who know and trust individual developers
verify the authenticity of a release based upon that personal trust.
This is IMHO a much easier problem to solve. These people if they
really know developers could simply drop this person a line and verify a
md5sum... They already have that connection.
The trust path only helps tell us that the key belongs to the person it
says it does. That doesn't mean the person is trustworthy, authorized
to do a subversion release, or someone who's code I would necessarily
want to use. So while the trust path solves the problem of knowing if
a key id belongs to someone, it doesn't solve the problem we need to
solve. You need an outside connection to the project in order for it to
do that.
The individual key signing in my proposal exists to:
a) Provide a way for developers to communicate to each other as part of
the release process without using the shared key.
b) Permit those that already know and trust us to use this stronger
method of authentication. (Yes I'm admitting it's a stronger form
provided that you know the people who's keys you're using).
c) Satisfy the people who don't like shared keys.
As such I don't consider it a complete solution without the shared key.
> We have clear agreement on the common portion, so (I assume) we're
> going to do at least that part.
I don't think we have an agreement at all. I think we disagree about
the problem we're trying to solve. Individual keys solve a different
problem than a shared key.
> It's perfectly fine to argue that the extra bit is important and
> should be implemented. (I'm not using "extra" in the sense of
> "superfluous", just needed an adjective to describe the non-common
> part, and "non-common" was too awkward.)
I see this as implementing the carriage without the horse.
> Maybe we should try releasing with a shared project key and see how
> much hassle it actually is. After all, we can stop using it anytime
> if we want. Dropping it wouldn't invalidate the other signatures in
> any way. And your points about relative security are excellent.
Obviously I'm okay with this. But I'd rather people understand what the
shared key is for.
--
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 19:22:05 2004