On Aug 27, 2012, at 11:21 AM, Rob Weir <robw...@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).
