On Mon, 2012-08-27 at 13:38 -0400, Jim Jagielski wrote: > On Aug 27, 2012, at 11:21 AM, Rob Weir <[email protected]> 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
