Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote
From: drew <drew@baseanswers.com>
To: ooo-dev@incubator.apache.org
In-Reply-To: <4EFCB089-566F-4B89-BF52-6DC811118EDD@jaguNET.com>
References: 
	 <CAP-ksogNw3hy0RrUOBELkShLrdABb5Vhz6Uw6cp-8KFsFTJMNg@mail.gmail.com>
	 <CAAS6=7jtBppzByUm8+TsVRDocoGMtKU3X854P-HdxrUHLC-JkQ@mail.gmail.com>
	 <1345500234.7229.10.camel@sybil-gnome> <50335AD5.7030903@gmail.com>
	 <CAEWfVJmqL_9UDjHFCrXOCNTG-eoDoMZKiZqmk5vCAKQg6kvDkA@mail.gmail.com>
	 <CAAS6=7hKBm6V8k75JDOvOXF1AK7qPdVV0PKTpn8CU-4JzWyLqQ@mail.gmail.com>
	 <7A2259B7-94CA-4C49-9247-42DF20F77CB9@comcast.net>
	 <CAP-ksoijwNSHf6NdamBg5BtwwdV4+fHvwDj1F+8U0oMnz7L5pQ@mail.gmail.com>
	 <CABD8fLVpyRWRNVQOo3AmAodSDrtZHAovDJDJemYr9pSC-nc+Zw@mail.gmail.com>
	 <CAP-ksoi4EqWmiaH4qL_gp6cSU6jAHX2GMKTJgexMTGb2c6b-3g@mail.gmail.com>
	 <CAG_bHowvapKSF8VriKwYch=XpJ+WiAca9Q0p0uRtiPSwtuy_Pw@mail.gmail.com>
	 <503A07EE.3060506@apache.org>
	 <4B9152D8-D5C9-4548-B90A-0BD6268FD372@jaguNET.com>
	 <OF799D66EE.3300B2AA-ON85257A67.00468B03-85257A67.004714BD@lotus.com>
	 <0C957131-5AAA-4CC7-9B6E-62EBB9F88D0D@jaguNET.com>
	 <CAP-ksojDV4y=uUSn39L_RCuT9bm587vHBuSNwWtFjOgfQ9iEog@mail.gmail.com>
	 <CAP-ksogq9Y9Kz4uDaNj=sVmwvpT02DhhzHWsNwB6bx =4HUhRtQ@mail.gmail.com>
	 <321A471A-84EB-45FA-99A5-83F126976708@jaguNET.com>
	 <CAP-ksojGjospiXpam80DhQA1K=H=K3kpSVw14v7r9dO6G4fCXg@mail.gmail.com>
	 <4EFCB089-566F-4B89-BF52-6DC811118EDD@jaguNET.com>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 27 Aug 2012 14:03:11 -0400
Message-ID: <1346090591.2449.24.camel@sybil-gnome>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Mon, 2012-08-27 at 13:38 -0400, Jim Jagielski wrote:
> On Aug 27, 2012, at 11:21 AM, Rob Weir <robweir@apache.org> wrote:
> 
> > 
> > Identity != Trust.
> > 
> > Identity + Reputation == Trust.
> > 
> > The signature only guarantees identity.
> 
> Signature does not guarantee reputation though. The point
> is that reputation is dependent upon identity. And
> identity is ensured via some sort of signature. And
> a signature does *nothing* to guarantee "trust" in
> and of itself.
> 
> > 
> > End users know absolutely nothing about Apache release process.  They
> > know brands.  So their view of trust is brand-based, not informed by
> > the technical minutia of Apache release process.  Of course, given a
> > suboptimal process, if bad releases result from this, then the brand
> > reputation will suffer over time.
> > 
> 
> Again, I have no idea what you are talking about.
> 
> People trust the Apache brand.
> They download Apache "stuff" from somewhere.
> That stuff is signed by an entity that is associated
> with the Apache brand.
> 
> What the "release process is" is moot.
> 
> > 
> > Today it is more likely that they see a binary called "OpenOffice",
> > with or without the Apache name, and without verifying the signature,
> > the user just installs it.  That is the sad state of end-user security
> > awareness today.
> > 
> > This is not going to get better by technology alone.  It will require
> > user education as well.
> > 
> 
> Agreed... 
> 
> > 
> > 1) The AOO 3.4.1 release ballot is defective because it refers to
> > binaries and Apache does not release binaries
> 
> The ASF releases code. PMCs vote on a SVN tag and on a release tarball
> (distribution) made from that tag. There is a direct and easily
> followed path between the bits the end-user gets and the bits that
> the PMC has determined as "the release."
> 
> The issue with voting on "just" a binary release is how is the
> providence of the code ensured... If I get a binary how can I,
> as an end-user, ensure that the binary was based on the official bits
> and was built in a way that didn't much around with those bits.
> *THAT* is what the AOO PPMC needs to work thru, since most end-user
> of AOO couldn't care a fig about the bits. But just because end-users
> don't care, or shouldn't care, doesn't mean that the PMC/PPMC
> can just wing it. Nor can it consider the binaries as "more important"
> than the code.
> 
> One possible scenario: The AOO PPMC/PMC is ready for a release
> and someone steps up to RM. He/she does the normal process and
> a release tag is created. At that point, binary RM's step up
> and, using that tag and a well-defined (and trackable) process,
> creates binaries and then sign that binary. In fact, that was/is
> my intent on wanting to be on the AOO PMC is to be the Apple OSX
> RM (that is, take on that responsibility).

Hello Jim,

YES 

AOO as ASF project, from ASF's perspective, must conform to the current
- well defined I think - steps for the source release. No argument here.

Jim's use of the term binary RM's and brief explanation, I believe, gets
to the crux of my concerns. I would add that I see some role of
responsibility for AOO PMC with regards to supporting the artifacts it
oversees - but this is in the context of how it affects on going
decisions on things such as LTS or bug/Security releases and the like
and I don't see anything in looking at other ASF projects that leads me
to believe any of that will be anything other then welcomed.


So - if I may be so bold. Reading email this morning my gut feeling is
that there is a lot of violent agreement going on.. I'm personally a bit
lost as to why the animation on the subject of the signature - is the
disagreement over who will own the signature file?

Thanks,

Drew