www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Inclusion of .class files within a Apache Source Release
Date Wed, 04 Jan 2017 13:33:41 GMT
Could you note the other solution here for completeness? Thx.

> On Jan 4, 2017, at 1:14 AM, Mark Struberg <struberg@yahoo.de.INVALID> wrote:
> 
> 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
> 


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


Mime
View raw message