Ben Reser <ben@reser.org> writes:
> 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).
Er, meta-discussion:
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.
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 :-).
We have clear agreement on the common portion, so (I assume) we're
going to do at least that part.
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.) 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.
But it *is* a proposal to do more than a current consensus, so I'm not
sure how a "-1" sentiment fits in there. Opposition-ish sentiment is
karmically inoperative in this context. It's like saying "I'm against
people not adopting this proposal." Well, naturally -- you wouldn't
be proposing it if you didn't want people to adopt it :-).
There's no negative space to this picture. We can only discuss the
proposal in positive terms.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 9 17:38:13 2004