On Mon, Aug 27, 2012 at 2:48 PM, Jim Jagielski <j...@jagunet.com> wrote: > > On Aug 27, 2012, at 2:13 PM, Rob Weir <robw...@apache.org> wrote: >> >>> 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. > > That is a totally different topic and, IMO, just muddies this > conversation. >
I think they are all connected, and should be considered together. You are free to disagree and ignore the parts that you are not interested in. >> >> 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. >> > > Gotcha. > >> 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. > > Again, this is, IMO at least, moot and inappropriate for the real > issue of this discussion. Yeah, we need better end-user education. > Point taken. Move on to actual PMC/PPMC issues... > Since this project does directly interact with end users, via support forums and user lists, user education is directly relevant. Again, feel free to ignore the parts that don't interest you. We have plenty of volunteers who like help users. >> >> 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. > > tradema...@apache.org... not a pertinent topic for this discussion. > PMCs have defined requirements and responsibilities in this area. Some are defined here: http://www.apache.org/foundation/marks/pmcs.html PMCs are also the first-point-of-contact for those who wish to use the trademarks, as well as for those reporting abuse. So this is entirely relevant. We have volunteers interested in that piece 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. >> >> >> 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. > > I would say that you are wrong and that the *vast* majority of > PMCs take the release process as the crucial issue that it is. > And if they don't't, then the PMCs are not doing what they should be > and should be corrected... > I didn't say they were not taking "the release process as the crucial issue that it is". I said that I believe that few PMCs are verifying that what is signed is exactly what was tagged in SVN. If your recall that was the concern that you raised about binaries. I'm just saying this is a concern about source tarballs as well and we should aim to raise the bar here, both for source and binaries. >> >> 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). >> > > "more securely"?? What kinda comment is that? Dis'ing a large segment of > the ASF PMCs, who have been doing releases well and for a LOT longer > than AOO, is NOT a way of garnering cooperation. And, to be honest, > this sort of elitist attitude does nothing to help the current community, > much less growing it. > Attempting to raise the bar on security and process should not be seen as threatening to existing ASF projects. Certainly those threatening our users have raised the bar since the ASF was founded. We need to keep pace as well. A climate that nurtures continuous improvement starts with stopping the insults against those who suggest that improvement is possible. > So, just to summarize, in this whole conversation the single solitary > point you've made is "we need to be serious about ensuring ASF-> > end-user bit integrity." > I've made several points, though obviously your interests lie with a subset of them. That is fine. I tried to put this in a context where other PPMC members can see how their efforts and contributions fit into the final end-user benefit. Some will find some parts more relevant than others, and in different ways. This is not a problem. Again, feel free to ignore the parts that don't interest you. In fact, you really don't even need to respond to those parts. Kind regards, -Rob > thanks
