www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de.INVALID>
Subject Re: Inclusion of .class files within a Apache Source Release
Date Wed, 04 Jan 2017 06:14:09 GMT
Hi Marvin!

All perfectly understandable. The point is that this class file is not even on the classpath.
In the meantime we also found another solution.

LieGrue,
strub

> Am 04.01.2017 um 04:39 schrieb Marvin Humphrey <marvin@rectangular.com>:
> 
> 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
> 


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


Mime
View raw message