Changing the subject to something more accurate due to thread drift. On Mon, Aug 27, 2012 at 1:38 PM, Jim Jagielski <[email protected]> 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. >
I've stated it twice. Maybe it would help if you rephrased what you think I was saying that wasn't clear? > 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. > As you know, that last step does not occur today. If it did, then we'd be closer. But we really need several things to come together: 1) Trust in the brand == reputation of Apache OpenOffice, partially based on historical reputation of "Apache", partially on historical reputation of "OpenOffice" and partially on the novel and recent combination. This reputation is one of our most valuable assets, and is what every user comes to the table with. 2) Digital signatures confirm the identity of our binaries and allow the user (via their platform) to reject out copies that have been modified or damaged. 3) However, the majority of users would be just as happy to install something that claimed it was OpenOffice, even if it were not signed. (Our 12 million downloads prove that). So when/if we do start signing, then user education needs to be an essential component of this. The platform vendors will be pushing this general idea in parallel via their deprecation of unsigned binaries. 4) Finally is the trademark protections. Even concerns 1-3 are addressed this doesn't stop someone from getting a signing certificate in the name of "Open Office" or "OpenOffice.com" or any other knock off names. Many (perhaps most) users would fall for this. Look at what happens today with knock-off domain names related to OpenOffice. So the trademark protections are a key part of this as well. This all works well for the ecosystem as well, since a number of projects historically have taken the core OpenOffice binaries and repackaged them, with added extensions, templates, clipart, etc. By having the core code already signed, we make it easier for them to do their more surface level bundling and still meet OS vendor signing requirements, provided they sign the installer. > 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. How does a downloader of a source tarball know that the process you described above was followed by a PMC? Aside from trust, they don't. They trust that the PMC follows a process that ensures that these things happen. There is not requirement today, for example, that source tarballs must be produced on clean machines run by Infra. The ASF trusts that PMC's will do what is necessary to ensure that the RM doesn't slip a backdoor into the source before zipping it up. But I bet if you did a survey you would find that few PMC's do a diff between the tagged SVN and the source tarball before doing a release. So room for error, room for malice, room for user harm even with source tarballs. IMHO, we should aim to create source tarballs that are more securely built than the average ASF project, as well as binaries to that same level. I'd recommend collecting points of vulnerability in the current process, then define a process that verifies each step, and look at ways to automate as much as possible. (Human error is itself a vulnerability). -Rob > *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).
