Re adding ooo-dev@ since this is STILL an AOO issue. On Aug 27, 2012, at 9:38 AM, Rob Weir <robw...@apache.org> wrote:
> On Mon, Aug 27, 2012 at 8:59 AM, Jim Jagielski <j...@jagunet.com> wrote: >> >> On Aug 27, 2012, at 8:56 AM, donald_harbi...@us.ibm.com wrote: >>> >>> Yes, that's what end users care about. But it's not sufficient for AOO >>> since we are seeking alternative distribution channels. >> >> What does that mean? Can I grok "alternative distribution channels" >> as "more mirrors" or something else? >> > > You probably don't see this on the server yet, but end-user operating > systems, both desktop and devices, both at OS level as well as in > browsers and with antivirus software, are shifting over to excluding > non-signed executable by default. Believe it or not, I actually use end-user OSs. I am right now! Wow! > This is equally true of software > distributed on CD's, via downloads, or listed in OS-vendor "stores". > That is the direction that the industry is going. Any desktop > application that ignores this trend will become unusable by most > users. Instead of detached digital signatures that Apache releases > already carry, the OS vendors expect integrated signatures via code > signing. > > Where I hear the churning is over whether the technological change - > code signing rather than detached PGP/GPG signatures -- means anything > different from a liability standpoint. One could argue that a > signatures merely vouches for authentication, integrity and > non-repudiation -- the classic guarantees of a digital signature. But > I'm hearing others suggest that the move from one technology to > another technology for signing suggests additional guarantees about > the content of the signed artifact, above and beyond what the ASF > normally offers. But of course, any additional liability is > explicitly disclaimed by the Apache License. > > So given that other Apache projects distribute binaries that are.... > > 1) approved by the PMC's > > 2) distributed on Apache mirrors > > 3) linked to as ASF products by project websites > > 4) accompanied by PGP/GPG detached signatures > > ...what additional liability do we believe comes from the > technological change from one signature mechanism to another? Or > specifically, what liability is added that is not already explicitly > disclaimed by ALv2? > A signature does 2 things: 1. Ensures that no bits have been changed 2. That the bits come from a known (and trusted) entity. The fact that we've used GPG-signed artifacts is immaterial, imo. But recall in all this that even when the PMC releases code, it is signed by the individual RM, and not by the PMC itself.
