[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: <kfogel_at_collab.net>
Date: 2004-04-13 17:46:20 CEST

Justin Erenkrantz <justin@erenkrantz.com> writes:
> Yes. If I were to see a key entitled 'Subversion Release Key' on,
> say, 1.0.2 then for 1.1, I don't see it, I could envision that users
> would be legitimately concerned that the key wasn't used to sign 1.1.
> So, if we introduce it, I think we must intend to use it for all
> subsequent releases. -- justin

You know, I'm turning this over in my mind, and must finally admit
that I just don't know how most users would react. Probably it would
be different for different people.

<shrug>

This thread will always be a contention generator because there isn't
a right answer here. Cryptography lures people into thinking about
things in a highly technical, mathematical way (because it can't be
understood otherwise), yet the real issues are social and not subject
to yes/no answers. It depends on the level and kind of care
individual humans give to key management, and on the different ways
users go about verifying releases. Put those two together, and you
get ("human factors")^2.

I know better than to try to declare a conclusion here. But if there
is a shared key, I will not use it nor sign it. A shared key greatly
increases the probability of our getting into a long and acrimonious
discussion about proper key management. Based on the evidence so far,
the chances of that discussion *not* being a huge and dismaying
gumption sink are close to zero. Smart projects avoid situations like
that :-).

Best,
-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 13 19:01:47 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.