Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
MIME-Version: 1.0
In-Reply-To: <CACLE=7OWV_u6CdYrsJ1exW7f0gcdeG-10-NZqMguYot_jkU1QQ@mail.gmail.com>
References: <CAOqetn_SQQV8z3tD+XtGiBNBXGEmogUbju-2aFAsOQBSROWK2A@mail.gmail.com>
 <531A8CB0-9ABF-4A45-97E6-2871034AC1A1@yahoo.de> <D49117E6.7FC45%aharui@adobe.com>
 <CACLE=7NyMBiDQu9wOxFXNpYHjAiVRYSep8pPdgJq4k78pPetdw@mail.gmail.com>
 <D491217E.7FC9E%aharui@adobe.com> <CACLE=7OWV_u6CdYrsJ1exW7f0gcdeG-10-NZqMguYot_jkU1QQ@mail.gmail.com>
From: Marvin Humphrey <marvin@rectangular.com>
Date: Tue, 3 Jan 2017 19:39:11 -0800
Message-ID: <CAAS6=7g_yDAQQM7HAMJ7=S-aGBfs8_owYOKajVTN3jkfKUDF4g@mail.gmail.com>
Subject: Re: Inclusion of .class files within a Apache Source Release
To: "legal-discuss@apache.org" <legal-discuss@apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Wed, 04 Jan 2017 03:39:40 -0000

On Tue, Jan 3, 2017 at 9:57 AM, Romain Manni-Bucau
<rmannibucau@gmail.com> wrote:

> About "no binary" vs "no compiled sources": it leads to the trust or not of
> the downloaded package which is guaranteed - between others - by the signing
> we do of the package, not by the extension (as explained it is easy to
> exploit a .png containing a .class). If you can't trust the signing of the
> source bundle then .class is the least issue you can get I fear so really
> not an issue.

> So concretely I read this thread as "do we trust our signing". If the answer
> is no then I think we have a big problem to solve but I'm not seeing why it
> would be the case at the moment.

Cryptographic signing is an important layer of security, but we need other
layers as well.  There are a number of different attack vectors we are
concerned about with regards to avoiding the distribution of untrusted
compiled code.

Consider the following scenarios (the first is worst):

1. A developer machine may be compromised.
2. A developer may be subject to coercion by organized crime or a state agent.
3. A developer may be malicious.

Deliberately contributing a malicious source code patch to an open source
project and getting it past code review is probably not that hard.  However,
such a contribution produces an audit trail; once the issue goes public, the
contributor will have to explain themselves.  That's extremely risky
for the threat agent and a given contributor could probably pull it off
once at most.

So, we believe that source control in conjunction with PMC review, commit
notifications, etc. is a reasonably good defense against trojan horses in the
form of source code.

However, our defenses weaken when we allow compiled code into our products.
If a developer's machine is compromised and a malicious build tool
installed[1], then compromised object code may end up in the repository with
the contributor and the PMC none the wiser!

Of the places that non-auditable code could show up in a project, the most
damaging would be in a compiled dependency, like a jar file, which is
eventually bundled into a library or executable.  Build or test code is harder
to exploit, but still theoretically a problem.  JPEGs in documentation we are
unlikely to worry over.

From a security standpoint, the ideal is to have everything in auditable
source form.  Sometimes it takes some workarounds for that to happen -- but
it's generally worthwhile.

Marvin Humphrey

[1] Examples of compiler attacks include XCodeGhost from fall 2015 and a
    "trusting-trust" hack on the Delphi compiler in 2009.

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org