incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From drew <>
Subject Re: [VOTE] Apache OpenOffice Community Graduation Vote
Date Mon, 27 Aug 2012 18:03:11 GMT
On Mon, 2012-08-27 at 13:38 -0400, Jim Jagielski wrote:
> On Aug 27, 2012, at 11:21 AM, Rob Weir <> 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,


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?



View raw message