AOO and Code Signing

[Rob Weir <ro...@apache.org>]

Changing the subject to something more accurate due to thread drift.

On Mon, Aug 27, 2012 at 1:38 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Aug 27, 2012, at 11:21 AM, Rob Weir <ro...@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.
>

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

Re: AOO and Code Signing

[Rob Weir <ro...@apache.org>]

On Mon, Aug 27, 2012 at 2:48 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Aug 27, 2012, at 2:13 PM, Rob Weir <ro...@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.
>
> trademarks@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

Re: AOO and Code Signing

[Jim Jagielski <ji...@jaguNET.com>]

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

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

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

trademarks@apache.org... 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." 

thanks