Greg Stein wrote on Wed, Oct 10, 2012 at 21:14:15 -0400: > On Wed, Oct 10, 2012 at 9:10 PM, Daniel Shahaf <[email protected]> > wrote: > > Greg Stein wrote on Wed, Oct 10, 2012 at 19:44:30 -0400: > >> I've read this entire thread (whew!), and would actually like to throw out > >> a contrary position: > >> > >> No signed keys. > >> > >> Consider: releases come from the ASF, not a person. > > > > Therefore, releases should be signed by the ASF as an organisation, not > > by individual persons. Right? > > I would be completely supportive of an Infra-managed private key for > signing releases. > > 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? > a long thread, for such little gain... my thought was "toss the > concept. throw out the keys." > > >... > > Daniel > > (infra hat off, devil's advocate hat on) > > hehe. And my devil's advocate is: "keys provide no additional benefit > for end users. demonstrate otherwise." > 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". > Cheers, > -g > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
