On 11/10/2015 09:59 PM, Luc Maisonobe wrote: > Le 09/11/2015 23:37, Thomas Neidhart a écrit : >> Hi all, >> >> in order to provide a work-around for the known remote code exploit via >> java de-serialization of malicious InvokerTransformer instances, I would >> like to start a vote to release Commons Collections 3.2.2 based on RC1. >> >> I would kindly ask people to review the RC especially wrt the following >> topics: >> >> * OSGI compatibility >> * reproducing the exploits and verifying that it provides protection >> * any kind of regression that this release might create with existing >> applications >> >> Notes: >> >> * the site will not be published, it just serves as a reference to >> access the various reports. After a successful vote, the current 4.X >> branch site will be updated with relevant information and published. >> >> * some tests might fail with various IBM JDK 6 JREs, these are known >> issues and have been worked-around in the 4.X branch but are not >> back-ported to this release. >> >> >> Collections 3.2.2 RC1 is available for review here: >> https://dist.apache.org/repos/dist/dev/commons/collections/ >> (svn revision 11092) >> >> Maven artifacts are here: >> >> https://repository.apache.org/content/repositories/orgapachecommons-1115/commons-collections/commons-collections/3.2.2/ >> >> Details of changes since 3.2.1 are in the release notes: >> >> https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt >> >> http://people.apache.org/builds/commons/collections/3.2.2/RC1/changes-report.html >> >> The tag is here: >> >> https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_3_2_2_RC1 >> (svn revision 1713561) > > It seems the revision is 1713556 rather than 1713561. > It is both what I see in svn and what was used to generate the > binaries in dist (according to the Implementation-Build element > in the MANIFEST.MF embedded within the jar). > >> >> Site: >> http://people.apache.org/builds/commons/collections/3.2.2/RC1/ >> >> Clirr Report (compared to 3.2.1): >> >> http://people.apache.org/builds/commons/collections/3.2.2/RC1/clirr-report.html >> >> RAT Report: >> >> http://people.apache.org/builds/commons/collections/3.2.2/RC1/rat-report.html > > The single file with unknown license in this report is > xdocs/style.project.css. It is a one line file that imports > commons-maven.css). The file has been unchanged since April 2008. > > Certainly not a blocker. > >> >> KEYS: >> https://www.apache.org/dist/commons/KEYS >> >> Please review the release candidate and vote. > > I first got a compilation error when attempting a compilation with maven > 3.3.3 and the default JVM on my system (java8 openJDK, on a Debian > stretch machine) > [ERROR] COMPILATION ERROR : > [INFO] ------------------------------------------------------------- > [ERROR] > /home/luc/tmp/downloaded-RC/dist/source/commons-collections-3.2.2-src-t/src/java/org/apache/commons/collections/map/MultiValueMap.java:[156,19] > remove(java.lang.Object,java.lang.Object) in > org.apache.commons.collections.map.MultiValueMap cannot implement > remove(java.lang.Object,java.lang.Object) in java.util.Map > return type java.lang.Object is not compatible with boolean > [ERROR] > /home/luc/tmp/downloaded-RC/dist/source/commons-collections-3.2.2-src-t/src/java/org/apache/commons/collections/MultiMap.java:[69,19] > remove(java.lang.Object,java.lang.Object) in > org.apache.commons.collections.MultiMap clashes with > remove(java.lang.Object,java.lang.Object) in java.util.Map > return type java.lang.Object is not compatible with boolean > [ERROR] > /home/luc/tmp/downloaded-RC/dist/source/commons-collections-3.2.2-src-t/src/java/org/apache/commons/collections/map/MultiKeyMap.java:[200,19] > remove(java.lang.Object,java.lang.Object) in > org.apache.commons.collections.map.MultiKeyMap cannot implement > remove(java.lang.Object,java.lang.Object) in java.util.Map > return type java.lang.Object is not compatible with boolean > [ERROR] > /home/luc/tmp/downloaded-RC/dist/source/commons-collections-3.2.2-src-t/src/java/org/apache/commons/collections/MultiHashMap.java:[334,19] > remove(java.lang.Object,java.lang.Object) in > org.apache.commons.collections.MultiHashMap cannot implement > remove(java.lang.Object,java.lang.Object) in java.util.Map > return type java.lang.Object is not compatible with boolean > > Then I forced maven to run using java7 and it was fine. The pom does > specify maven.compile.source and maven.compile.target to be 1.2. So > I don't think it is a real problem with the source code, but rather > a problem with maven 3.3.3 and openJDK8 (I also do have some problems > with [math], so I usually force maven to run with Java7). > > So I don't think this probelm is a blocker.
yes, I forgot to mention this. Collections 3 can not be compiled with JDK 8 because the Map interface got a new default method with the same name as one already existing in MultiValueMap. We had to change this for Collections 4. Thomas >> >> This vote will close no sooner that 72 hours from now, i.e. after 2300 >> GMT 12-November 2015 >> >> [X] +1 Release these artifacts > > Luc > >> [ ] +0 OK, but... >> [ ] -0 OK, but really should fix... >> [ ] -1 I oppose this release because... >> >> Thanks, >> >> Thomas >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
