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 Tue, 03 Jan 2017 18:10:00 GMT
already fixed it putting the bytecode in the sources instead of files


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-03 19:07 GMT+01:00 Mark Struberg <struberg@yahoo.de.invalid>:

> I propose to simply rename it to .noclass and we are done ;P
>
> LieGrue,
> strub
>
>
> > Am 03.01.2017 um 18:57 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> >
> > 2017-01-03 18:42 GMT+01:00 Alex Harui <aharui@adobe.com>:
> > Hi Romain,
> >
> > AIUI, it isn't a "no binary" policy, it is a "no compiled sources"
> policy.  Distributing a compiled binary puts the responsibility of the
> effects of executing that code on the ASF and should scare away customers.
> You are taking a big chance by running the source build script if it
> executes that .class file if you can't verify it came from the source you
> said it did.    Sure a customer might have a bad tool chain that compiles
> the sources into a bad binary, but that is not the ASF's responsibility.
> >
> >
> > 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.
> >
> > Also for this particular case: these .classes are in *test* resources so
> not used until you run tests and if you do so you likely want to have them.
> When I spoke of bad tool chain it was about the project itself, not the
> user: if you don't use that trick you need to generate classes in the build
> but NOT in the test-classes folder to ensure these classes are NOT in the
> classpath (point of having them as resources). Most of solutions would
> break IDE support and would make entry cost of the project high for a poor
> gain, that is why it got done this way. Also note that these .class are in
> the "wrong" folder regarding their package and are NOT classes the way they
> are stored. Without some actual file copy you will not load them by default
> even if in the classpath. So running them needs some knowledge on them
> which reduces again the risk.
> >
> > BTW not the first time this trick is used @asf cause it is the best
> compromise for such things (not breaking dev tooling).
> >
> > 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.
> >
> >
> > -Alex
> >
> > From: Romain Manni-Bucau <rmannibucau@gmail.com>
> > Reply-To: "legal-discuss@apache.org" <legal-discuss@apache.org>
> > Date: Tuesday, January 3, 2017 at 9:17 AM
> > To: "legal-discuss@apache.org" <legal-discuss@apache.org>
> > Subject: Re: Inclusion of .class files within a Apache Source Release
> >
> > Please don't diverge: too much
> >
> > - can we do better: probably, even if "process-test-resources life-cycle
> goal seems read-made for this" doesn't really help since it requires a
> build setup we likely don't want to ensure we have these classes only for
> some part of some tests and not the whole test phase. it also breaks IDE
> support to do it this way and reduce contributions capabilities but that's
> another topic....
> > - is it legal: yes (otherwise as mentionned all projects with binary
> resources would be illegal)
> > - is it unsecured? likely as much as generating bytecode at runtime so
> probably out of topic for here too. Also note that a picture (.png for
> instance) can be a .class and be loaded by a JVM is correctly launched so
> security there is not really a point IMHO.
> >
> > In summary I don't see why it makes so much noise for really an
> implementation detail and I'm not seeing what is the alternative proposal
> to not distribute ANY binary if we care about it? Do I miss an important
> point?
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >
> > 2017-01-03 18:05 GMT+01:00 Alex Harui <aharui@adobe.com>:
> >
> >
> > On 1/3/17, 3:51 AM, "Mark Struberg" <struberg@yahoo.de.INVALID> wrote:
> >
> > >The class file in question was added by ASF member rmannibucau under
> ALv2
> > >as a >>resource<< and not as a source file.
> > >The original file of course has the ASF license header, but the 'class'
> > >resource is still checked in to our SVN as .class file.
> > >
> > >This is for testing some bytecode stuff in OpenBebBeans. We could
> > >probably later change this to have another project module, compile it,
> > >unpack it, copy it over, blablabla.
> > >But that doesn't change anything about the fact that this file is ALv2
> > >licensed. But since it's a binary it obviously does not have any ALv2
> > >>>SOURCE<< header.
> > >
> > >In other words: this .class file is a test resource and handled exactly
> > >the same like a png or jpeg file.
> > >
> > >I don't see any legal problem.
> >
> > There may not be a legal problem, but I thought the reason behind the "no
> > compiled code" rule/policy was about verification/auditing of the release
> > artifact.  See Marvin Humphrey [1].
> >
> > Anybody auditing a release would scan each file for headers and find
> > binaries.  They could examine binaries proposing to be image files and
> > verify that they have image file headers and are thus safe to open in an
> > application.  But verification of the safety of executing a .class file
> > seems risky to me.  I'm surprised to learn that some ASF projects allow
> it.
> >
> > -Alex
> >
> > [1]
> > https://mail-archives.apache.org/mod_mbox/www-legal-
> discuss/201606.mbox/%3c
> > CAAS6=7gVXGHqeKVeFV_r1849Qpi0+Ca0jc2QWQBQfRdZnCwVpA@mail.gmail.com%3e
> >
> > >
> > >LieGrue,
> > >strub
> > >
> > >
> > >> Am 03.01.2017 um 12:45 schrieb John D. Ament <johndament@apache.org>:
> > >>
> > >> Hi,
> > >>
> > >> While looking at [1] and looking at a proposed Apache OpenWebBeans [2]
> > >>it was discovered that .class files were contained in the source
> > >>release.  It seems in the past that image files were generally
> > >>considered OK in source releases, since they typically had to do with
> > >>building websites, the traceability of the image was easy to discover.
> > >>
> > >> .class files are the compiled output from .java source files (as well
> > >>as .groovy and other JVM languages, depending on how you compile).
> > >>Since they are compiled output, it seems they shouldn't be in a source
> > >>release.  However, the only true policy I could find that it violated
> > >>was that we require appropriate licensing [3] and there is no way to
> > >>verify the licensing of these files.
> > >>
> > >> So I'm wondering 1. is that accurate? and 2. is there an acceptable
> way
> > >>to verify that the license is correct?
> > >>
> > >> [1]:
> > >>http://www.apache.org/dev/release.html#what-must-every-release-contain
> > >> [2]:
> > >>https://lists.apache.org/thread.html/869c739764d5d55d81199576d730d4
> 85d66d
> > >>f8be17ae16398dd7ca1f@%3Cdev.openwebbeans.apache.org%3E
> > >> [3]: http://www.apache.org/dev/release-publishing.html#valid
> > >>
> > >
> > >
> > >---------------------------------------------------------------------
> > >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