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 15:55:20 GMT
What if we just add the original Java file with License and JavaDoc explaining the details
in a NON-source folder like src/test/deployables. PLUS keeping the class file (compiled from
this Java file via java) in SVN as well?

-> reproducible
-> no need for javac, ant etc
-> no legal beef

We could ofc compile that java file on the fly during the build. But then we need to make
care that it doesn't end up on the normal classpath, and not confusing the IDE. It should
not get treated as a project source file.  We could do that via embedding ant or exec javac,
but all that would make the build much more complicated.

wdyt?

LieGrue,
strub


> Am 04.01.2017 um 16:45 schrieb Romain Manni-Bucau <rmannibucau@gmail.com>:
> 
> @Jim: for now the bytecode is a static variable in a source file. Doesn't change much
but keeps the same advantages and matches all constraints of this thread in term of source
and dev flow (even if ugly).
> 
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> 
> 2017-01-04 14:33 GMT+01:00 Jim Jagielski <jim@jagunet.com>:
> 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
> 
> 


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


Mime
View raw message