Re: PROPOSAL: GPG Signing of Releases

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:

        http://www.unixsoft.org/apache/httpd/#sig
        http://httpd.apache.org/dev/verification.html

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

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