incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject AOO and Code Signing
Date Mon, 27 Aug 2012 18:13:01 GMT
Changing the subject to something more accurate due to thread drift.

On Mon, Aug 27, 2012 at 1:38 PM, Jim Jagielski <> wrote:
> On Aug 27, 2012, at 11:21 AM, Rob Weir <> 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 "" 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


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

View raw message