[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: PROPOSAL: GPG Signing of Releases

From: Ben Reser <ben_at_reser.org>
Date: 2004-04-07 02:39:44 CEST

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.

> 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 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 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 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.

-- 
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 Wed Apr 7 02:39:59 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.