Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 275FFD80F for ; Mon, 27 Aug 2012 14:16:31 +0000 (UTC) Received: (qmail 81749 invoked by uid 500); 27 Aug 2012 14:16:29 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 81611 invoked by uid 500); 27 Aug 2012 14:16:29 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 81596 invoked by uid 99); 27 Aug 2012 14:16:29 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Aug 2012 14:16:29 +0000 Received: from localhost (HELO mail-vc0-f175.google.com) (127.0.0.1) (smtp-auth username robweir, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Aug 2012 14:16:29 +0000 Received: by vcbfy27 with SMTP id fy27so4328638vcb.6 for ; Mon, 27 Aug 2012 07:16:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.10.148 with SMTP id pa20mr11509330vcb.26.1346076988303; Mon, 27 Aug 2012 07:16:28 -0700 (PDT) Received: by 10.220.197.78 with HTTP; Mon, 27 Aug 2012 07:16:28 -0700 (PDT) In-Reply-To: <5F928510-04E3-4EE7-9547-0486F161C5C1@jaguNET.com> References:

<1345500234.7229.10.camel@sybil-gnome> <50335AD5.7030903@gmail.com>

<7A2259B7-94CA-4C49-9247-42DF20F77CB9@comcast.net>

<503A07EE.3060506@apache.org> <4B9152D8-D5C9-4548-B90A-0BD6268FD372@jaguNET.com> <0C957131-5AAA-4CC7-9B6E-62EBB9F88D0D@jaguNET.com> <5F928510-04E3-4EE7-9547-0486F161C5C1@jaguNET.com> Date: Mon, 27 Aug 2012 10:16:28 -0400 Message-ID: Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote From: Rob Weir To: ooo-dev@incubator.apache.org Cc: "general@incubator.apache.org" Content-Type: text/plain; charset=UTF-8 On Mon, Aug 27, 2012 at 9:57 AM, Jim Jagielski wrote: > Re adding ooo-dev@ since this is STILL an AOO issue. > > On Aug 27, 2012, at 9:38 AM, Rob Weir wrote: > >> On Mon, Aug 27, 2012 at 8:59 AM, Jim Jagielski wrote: >>> >>> On Aug 27, 2012, at 8:56 AM, donald_harbison@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! > I did not mean to imply otherwise. But I am quite confident that few, if any other Apache projects are developing end-user software, so they might not be aware of this trend from the software development perspective. >> 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. > Almost. It doesn't guarantee trust. CA's don't require any specific level of software quality assurance before they issue a certificate. Any trust is implied by association with the identity of the signer. So it is a brand association. This is similar to the association that comes with association with a project's release announcement, or from distribution via Apache mirrors, or links from Apache websites. These all imply -- in one degree or another -- an association with Apache, and the trust that flows from that. But what code signing does do is help protect ASF reputation. By having the binaries signed we can distance ourselves from those who distribute versions of AOO with virus and malware attached. Again, this is something you probably don't see in the server world, but it is quite common with popular end-user open source software. So trust (reputation) is important. But we're already seeing that trust and reputation can be hurt by lack of code signing. > The fact that we've used GPG-signed artifacts is immaterial, imo. > To a savvy user the use of the detached digital signature can provide exactly the same assurances that code signing would do. Exactly the same thing. It just happens to be that the industry has moved toward a CA model rather than a web of trust model. > 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. > Correct. But the concerns in the thread were about individual liability. Having an individual signature (whether GPG/PGP or Authenticode) certainly doesn't make the story any better. So I wonder if the best solution here is to make it clear in the language of the certificate that it is an "unofficial, convenience binary"? -Rob