[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: John Peacock <jpeacock_at_rowman.com>
Date: 2004-04-13 19:29:53 CEST

kfogel@collab.net wrote:
> 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.

I just read through the Apache pages here:


and although it requires multiple steps (and at least one face to face meeting
for full trust), it is probably a workable solution for Subversion as well.

As I understand it, the use of a shared key means that the release is always
signed by a single key, which is itself cross-signed by multiple individual
keys. That would mean that a given end user would have to install at most the
shared key and one personally verified key that has signed the shared key in
order to have a full trust relationship.

Not using a shared key means that the key used to sign the release would vary
over time. In this case, the entire contents of the project KEYS file be
imported, but again only a single personally verified key will activate the web
of trust. But as long as the web of trust were maintained, there would be no
more interaction required in order to verify the signature(s).

Is that a fair assessment? If so, then I don't see why the shared key is that
significantly superior to the web of trust that Apache itself is using.

My 2 cents


John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
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:30:10 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.