> -----Original Message-----
> From: Ben Reser [mailto:ben@reser.org]
> Sent: Wednesday, April 07, 2004 2:40 AM
> To: dev@subversion.tigris.org
> Subject: Re: PROPOSAL: GPG Signing of Releases
>
>
> On Tue, Apr 06, 2004 at 04:43:31PM -0700, Justin Erenkrantz wrote:
> > Oh, yuck. We shouldn't be dependent upon the CollabNet folks to sign a
> > release.
>
> We're already dependent upon them to upload the package. It's just one
> more step for them to do when uploading.
If that is really true we should solve that. Anyone with Download Manager
privilidges is able to upload AFAIK. The one thing non-collab folks cannot
currently do is update the website, but that too can be fixed.
> > I've maintained before that we shouldn't have a group key and have stated
> > my rationale previously.
>
> I don't think you've responded to my response to your rationale. And
> all you're doing here is restating that you don't like the idea.
>
> > I hereby vote -1 (i.e. non-veto No) against this. I think a shared key is
> > about the worst thing we could do to solve this problem.
>
> Why? In many respects this proposal specifically includes
> considerations to answer the rationale you've given before.
I had a reply sitting in my drafts since when Karl sent out the original
mail about the shared key, but never got around to sending it. Let me
try again...
As Ben Laurie points out, shared keys are bad for the obvious reasons:
* they're shared, so their has to be another shared form of trust
* the key has to be revoked as soon as a single person with access to
the key leaves the project
And, there is a bottleneck: we need someone with access to the shared
key to sign the release. In this scenario this would be one of the
CollabNet developers. Not too bad, but not nessecary either.
From another post (sorry for not getting the full post):
"
If you really want to be that paranoid about each other then fine, only
have one person at CollabNet be responsible (i.e. have access) to the
project key. When that person leaves then we can regen a new key. Do
people really come and go on this project that often that we'll need to
be doing this all the time?
"
How is that different from saying: you can trust all keys
which are in http://svn.collab.net/repos/svn/KEYS for signing a
release. In the paragraph above the project key _is_ an individual
key, just not with a person name attached, but a project name.
> I pretty much think by not having a project key we'll have people who
> simply ignore validation because they simply won't go to the bother of
> getting a trust path
This is not our problem, nor should we make it ours. The exact same
thing goes for many software packages. The verification is the job
of the user, not us. Educating is a better fix, and even there we
should only go that far, IMHO.
> or they'll just check to make sure the signature is
> good (not necessarily trusted). By doing both those that consider the
> project key insecure can simply ignore it. Those that can't or won't do
> a trust path can simply ignore the individual signatures. Other people
> can pay attention to all the keys.
I think that signing with multiple keys is already going the extra effort
towards making it easier on the user. I also think that if we increase our
keys connectedness, there will already be a trust path between all the
signing keys, which makes signing with multiple keys redundant... ;)
But for now, sure, go with multiple sigs. The policy can simply be:
if you vote +1 on the release, your vote only counts when you attach
a sig.
> I don't see any reason why we can't put up a document that explains
> all of this. We ought to put up a document explaining how to do the
> verification anyway.
How to do verification is something to document, yes.
http://httpd.apache.org/dev/verification.html could be a starting point.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 7 08:37:22 2004