[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-13 22:22:33 CEST

On Tue, Apr 13, 2004 at 02:08:33PM -0400, John Peacock wrote:
> >The difference is Apache's technique forces all users that want to use
> >GPG to verify a release to buy into the web of trust. I don't believe
> >this is a realistic requirement. That's not to say I have anything
> >against the web of trust.
> And that is the piece I am still missing then. How does the user establish
> trust with the shared key without trusting one of the other keys that
> signed the shared key? Again, a single F2F key exchange is required. It
> just winds up being a degenerate form of the web of trust concept (single
> chain rather than multiple).

I've explained it dozens of times. The same way you'd verify a md5 sum.
Actually you have to do the same thing no matter what. Even if you have
a web of trust to Joe Well Connected who signed such a certificate, that
doesn't prove that Joe Well Connected has anything to do with the
project. All it means is that Joe Well Connected is a real person who
someone that you trust to verify an identity before signing a key has
signed someone elses key in the path.

The only way to verify such a key is to find multiple independent
sources of the key. We do that by posting the key information in many
places. Our website, our email announcements, by asking someone on IRC,
or any other communication medium.

To be honest the signatures on the shared key aren't even necessary.
They're nice in that they enable people using the web of trust to also
trust the shared key. But they are utterly unnecessary in my view of
what makes the shared key useful to the people that would want it as
opposed to individual keys.

The benefit of signing the shared key is that it simply makes it harder
to duplicate it. But then if we set appropriate expectations of how we
will announce the fingerprint of the key and how we would revoke and
regenerate a new key I don't think these are big issues.

> Are there significant numbers of people who object to the web of trust
> concept that you are trying to satisfy? I think it is pretty innocuous
> that if I am going to ask someone to meet me to establish their identity
> (so I could trust their key) that I would do the same in return (i.e. join
> the web of trust).

It's not that they might necessarily object to it. It's that they may
not understand how to use it. Or that they may not have someone
available that they can meet with to establish a path. Those of us that
live in larger cities in more industrialized countries find this pretty
easy to do. But I grew up in Kansas. I know it would be darn hard to
find someone that knows what PGP/GPG is let alone has a well connected
key. If I can't afford to travel then I can't get into the web of

> I suspect that most people will ignore whatever key we signed the release
> with, some people will continue use the MD5, a few will check the
> fingerprint of the key, and only a relatively small number will go the full
> route of F2F meeting to establish trust. For those last group, we should
> go to the easiest method which would satisfy them; even you admit that
> using a shared key requires more careful controls than multiple
> cross-signed developer keys.

I don't think it requires that we do that. I think it's prudent. The
same measures would be prudent with individual keys as well. But that's
pretty much impossible to ask of people. If we want to require the same
measures with individual keys we'd need separate keys just for signing
subversion software. I know I use my key daily. There's just no way I
can keep it offline all the time.

If we ask people to use separate keys then we are definitely starting
with a blank web of trust. Which means intially the keys won't be very
useful to validate a release with. But then the same thing is true of a
shared key. Initially it would be very untrustworthy. After I've seen
a key used to sign a release 3 times that I can verify other ways I
start trusting that key.

I could do the same thing with individual keys. But if the individual
keys change from release to release, I'll find it more difficult to do

At any rate I'm not going to spend anymore time on this. All I'm doing
is repeating myself. If people aren't convinced or don't understand I
doubt they're going to. So i won't be responding to further emails on
this subject. I won't be trying to make a shared key because I'm
frankly sick of writing long emails on the subject with no apparent

Ben Reser <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 Tue Apr 13 22:23:29 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.