www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Inclusion of .class files within a Apache Source Release
Date Wed, 04 Jan 2017 15:45:33 GMT
@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 <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

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
>
>

Mime
View raw message