www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: Inclusion of .class files within a Apache Source Release
Date Wed, 04 Jan 2017 03:39:11 GMT
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

View raw message