incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: key signing
Date Thu, 11 Oct 2012 01:40:18 GMT
On Wed, Oct 10, 2012 at 9:35 PM, Daniel Shahaf <> wrote:
> Greg Stein wrote on Wed, Oct 10, 2012 at 21:14:15 -0400:
>> My point is that our instructions to users don't really incorporoate
>> the notions of "keys", and (thus) provide near-zero utility. For such
> So, provide better instructions?

That's the implication that I'm getting at... rip out all the key
stuff, and just talk about the SHA1 checksums.

> One benefit I named in my next-to-last message: upon a new release,
> users who downloaded the previous release and its signature can verify
> that the new release was signed by the same entity that signed the
> previous release.  This binds releases to each another.
> Shane hinted at another: a person who signs a release using the same key
> he uses for day-to-day dev@ work links the release not to his legal
> identity but to his dev@ identity.  This binds releases to people doing
> dev work.
> SHA-1 checksums don't provide any binding whatsoever, other than
> "whoever generated the checksum was looking at the same file I am
> looking at".

I understand there is no binding. I'm only considering a binding
against the ASF. It is residing on our infrastructure, its checksum
matches, therefore it must be authentic.

Does the extra glue really matter? Do we really need to figure out key
signing parties? What are we truly getting out of this?

I look at the "glue" of the committer's identifier. I'm posting to
dev@ as gstein, and then I commit the tarball artifact as gstein.
Binding is now complete.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message