incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: AOO and Code Signing
Date Mon, 27 Aug 2012 18:48:17 GMT

On Aug 27, 2012, at 2:13 PM, Rob Weir <> 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

> 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.

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...

> 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 "" 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. not a pertinent topic for this discussion.

> 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...

> 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.

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." 


View raw message