Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
I agree that the CSS file does not have an AL header, however it is only one line so it is at best doubtful that it needs one. There is little or no evidence of originality / creative expression in that one line. The daemon css file on the other hand is longer than the AL header, so needs the header. +1 to the release On 11 November 2015 at 09:56, Thomas Neidhartwrote: > On 11/10/2015 11:41 PM, Gary Gregory wrote: >> On Tue, Nov 10, 2015 at 2:22 PM, Thomas Neidhart >> wrote: >> >>> On 11/10/2015 10:52 PM, Gary Gregory wrote: Hi all: -1 Sorry, the RAT failure needs to be handled one way or another: exclude >>> the files or add headers: Unapproved licenses: data/test/NullComparator.version2.obj1 data/test/NullComparator.version2.obj2 xdocs/style/project.css I imagine the obj files can be excluded but the CSS file can just have a header added, just like >>> https://svn.apache.org/repos/asf/commons/proper/daemon/trunk/src/docs/daemon.css It's just messy to rush this through without dotting the i's and so on. >>> >>> yeah, I did not see the 2 NullComparator files as the problem appears >>> only on Windows. The same happened for the Collections 4 release, and I >>> forgot about it. >>> >>> @css: wtf, are you serious to vote with -1 because of that and complain >>> about the RC being messy? I mean, I can handle it if there are real >>> issues to be fixed, and I had planned to cancel the VOTE anyways to make >>> some more adjustments but something like that is just ridiculous. Just >>> take a look at some other published commons releases and count the >>> number of RAT errors, even for source files. >>> >> >> Sorry, two wrongs to do make a right. If other Commons components have made >> a mess of specific releases in the past, then that's sad. Either the RAT >> report is clean or it is not. If it is clean, I have to assume that >> exclusions in the POM for specific files or types of files have been done >> with careful consideration and that I can always go digging in the commit >> log to see a hopefully useful comment as to why the exclusion was made. >> >> Since this is a release to address a security issue, I would have hoped >> that all details would have been handled with extra care. >> >> I'd never get away with a sloppy release at work, and I hope I won't have >> to here either. >> >> In any case, a -1 is not a veto on a vote thread like it is on a commit, so >> this vote may yet pass. It's up to you as the RM to decide what to do. >> >> I know that cutting releases is still a pain, we have a lot of gymnastics, >> it's not like pushing a button, but that' what we're stuck with for now. > > you complain about false positives in a code base that has not been > released in 8 years and call my work messy. I have seen the css alert, > but thought I can safely ignore it, as it is anyway obsolete (pointing > to a non-existing css on the apache homepage). > > People blame Apache for not providing a fix in 9 months for a known > exploit and we are arguing about totally unimportant issues. > > I explicitly asked for review in areas that *are* important, e.g. OSGI > compatibility, as the build/release chain has changed quite a lot in the > last 8 years, and I wanted verification that the 3.2.2 release can > really be used in all areas. But no, we talk about a missing AL header > in a one line css file. > > Frankly, I am pissed because I spent the last days working on this while > my baby is teething and would have certainly better things to do. > > I will continue with the release as it is too important, but I am not > sure any more that I want to make another release for commons in the future. > > 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
Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
On Nov 11, 2015 1:56 AM, "Thomas Neidhart"wrote: > > On 11/10/2015 11:41 PM, Gary Gregory wrote: > > On Tue, Nov 10, 2015 at 2:22 PM, Thomas Neidhart < thomas.neidh...@gmail.com> > > wrote: > > > >> On 11/10/2015 10:52 PM, Gary Gregory wrote: > >>> Hi all: > >>> > >>> -1 > >>> > >>> Sorry, the RAT failure needs to be handled one way or another: exclude > >> the > >>> files or add headers: > >>> > >>> Unapproved licenses: > >>> > >>> data/test/NullComparator.version2.obj1 > >>> data/test/NullComparator.version2.obj2 > >>> xdocs/style/project.css > >>> > >>> > >>> I imagine the obj files can be excluded but the CSS file can just have a > >>> header added, just like > >>> > >> https://svn.apache.org/repos/asf/commons/proper/daemon/trunk/src/docs/daemon.css > >>> > >>> It's just messy to rush this through without dotting the i's and so on. > >> > >> yeah, I did not see the 2 NullComparator files as the problem appears > >> only on Windows. The same happened for the Collections 4 release, and I > >> forgot about it. > >> > >> @css: wtf, are you serious to vote with -1 because of that and complain > >> about the RC being messy? I mean, I can handle it if there are real > >> issues to be fixed, and I had planned to cancel the VOTE anyways to make > >> some more adjustments but something like that is just ridiculous. Just > >> take a look at some other published commons releases and count the > >> number of RAT errors, even for source files. > >> > > > > Sorry, two wrongs to do make a right. If other Commons components have made > > a mess of specific releases in the past, then that's sad. Either the RAT > > report is clean or it is not. If it is clean, I have to assume that > > exclusions in the POM for specific files or types of files have been done > > with careful consideration and that I can always go digging in the commit > > log to see a hopefully useful comment as to why the exclusion was made. > > > > Since this is a release to address a security issue, I would have hoped > > that all details would have been handled with extra care. > > > > I'd never get away with a sloppy release at work, and I hope I won't have > > to here either. > > > > In any case, a -1 is not a veto on a vote thread like it is on a commit, so > > this vote may yet pass. It's up to you as the RM to decide what to do. > > > > I know that cutting releases is still a pain, we have a lot of gymnastics, > > it's not like pushing a button, but that' what we're stuck with for now. > > you complain about false positives in a code base that has not been > released in 8 years The time is irrelevant IMO. If we cut a release, it should up to today's standard, again IMO. and call my work messy. Don't take it personally. Perhaps read "The four agreements". I have seen the css alert, > but thought I can safely ignore it, as it is anyway obsolete (pointing > to a non-existing css on the apache homepage). > > People blame Apache for not providing a fix in 9 months for a known > exploit and we are arguing about totally unimportant issues. > > I explicitly asked for review in areas that *are* important, e.g. OSGI > compatibility, as the build/release chain has changed quite a lot in the > last 8 years, and I wanted verification that the 3.2.2 release can > really be used in all areas. If OSGi is important to you, then you can create a test that embeds the jar in a container. It's pain, sure, but it's doable. But no, we talk about a missing AL header > in a one line css file. > > Frankly, I am pissed because I spent the last days working on this while > my baby is teething and would have certainly better things to do. Here we get to the bottom of it, yes, balacing work and family is a challenge for me as well. Gary > > I will continue with the release as it is too important, but I am not > sure any more that I want to make another release for commons in the future. > > Thomas > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
On 2015-11-09, Thomas Neidhart wrote: > 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. +1 Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[CANCEL][VOTE] Release Commons Collections 3.2.2 Based on RC1
On 11/09/2015 11:37 PM, Thomas Neidhart wrote: > 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) > > 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 > > KEYS: > https://www.apache.org/dist/commons/KEYS > > Please review the release candidate and vote. > > This vote will close no sooner that 72 hours from now, i.e. after 2300 > GMT 12-November 2015 > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... Hi, after careful consideration, I decided to cancel this vote to apply the fix for InvokerTransformer to all classes in the functor package that are serializable and use reflection. Additionally, the fix will be applied in a symmetric way, i.e. serialization of an unsafe class will be blocked as well. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
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. > > 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
Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
Hi all: -1 Sorry, the RAT failure needs to be handled one way or another: exclude the files or add headers: Unapproved licenses: data/test/NullComparator.version2.obj1 data/test/NullComparator.version2.obj2 xdocs/style/project.css I imagine the obj files can be excluded but the CSS file can just have a header added, just like https://svn.apache.org/repos/asf/commons/proper/daemon/trunk/src/docs/daemon.css It's just messy to rush this through without dotting the i's and so on. There is also the issue of the possibly wrong revision being tagged or being used in the VOTE email thread. That can be fixed for RC2 as well. Gary On Mon, Nov 9, 2015 at 2:37 PM, Thomas Neidhart <thomas.neidh...@gmail.com> wrote: > 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) > > 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 > > KEYS: > https://www.apache.org/dist/commons/KEYS > > Please review the release candidate and vote. > > This vote will close no sooner that 72 hours from now, i.e. after 2300 > GMT 12-November 2015 > > [ ] +1 Release these artifacts > [ ] +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 > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
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.c
Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
On Tue, Nov 10, 2015 at 2:22 PM, Thomas Neidhart <thomas.neidh...@gmail.com> wrote: > On 11/10/2015 10:52 PM, Gary Gregory wrote: > > Hi all: > > > > -1 > > > > Sorry, the RAT failure needs to be handled one way or another: exclude > the > > files or add headers: > > > > Unapproved licenses: > > > > data/test/NullComparator.version2.obj1 > > data/test/NullComparator.version2.obj2 > > xdocs/style/project.css > > > > > > I imagine the obj files can be excluded but the CSS file can just have a > > header added, just like > > > https://svn.apache.org/repos/asf/commons/proper/daemon/trunk/src/docs/daemon.css > > > > It's just messy to rush this through without dotting the i's and so on. > > yeah, I did not see the 2 NullComparator files as the problem appears > only on Windows. The same happened for the Collections 4 release, and I > forgot about it. > > @css: wtf, are you serious to vote with -1 because of that and complain > about the RC being messy? I mean, I can handle it if there are real > issues to be fixed, and I had planned to cancel the VOTE anyways to make > some more adjustments but something like that is just ridiculous. Just > take a look at some other published commons releases and count the > number of RAT errors, even for source files. > Sorry, two wrongs to do make a right. If other Commons components have made a mess of specific releases in the past, then that's sad. Either the RAT report is clean or it is not. If it is clean, I have to assume that exclusions in the POM for specific files or types of files have been done with careful consideration and that I can always go digging in the commit log to see a hopefully useful comment as to why the exclusion was made. Since this is a release to address a security issue, I would have hoped that all details would have been handled with extra care. I'd never get away with a sloppy release at work, and I hope I won't have to here either. In any case, a -1 is not a veto on a vote thread like it is on a commit, so this vote may yet pass. It's up to you as the RM to decide what to do. I know that cutting releases is still a pain, we have a lot of gymnastics, it's not like pushing a button, but that' what we're stuck with for now. Gary > > Thomas > > > > > There is also the issue of the possibly wrong revision being tagged or > > being used in the VOTE email thread. That can be fixed for RC2 as well. > > > > Gary > > > > On Mon, Nov 9, 2015 at 2:37 PM, Thomas Neidhart < > thomas.neidh...@gmail.com> > > wrote: > > > >> 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) > >> > >> Site: > >> htt
Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
On 11/10/2015 10:52 PM, Gary Gregory wrote: > Hi all: > > -1 > > Sorry, the RAT failure needs to be handled one way or another: exclude the > files or add headers: > > Unapproved licenses: > > data/test/NullComparator.version2.obj1 > data/test/NullComparator.version2.obj2 > xdocs/style/project.css > > > I imagine the obj files can be excluded but the CSS file can just have a > header added, just like > https://svn.apache.org/repos/asf/commons/proper/daemon/trunk/src/docs/daemon.css > > It's just messy to rush this through without dotting the i's and so on. yeah, I did not see the 2 NullComparator files as the problem appears only on Windows. The same happened for the Collections 4 release, and I forgot about it. @css: wtf, are you serious to vote with -1 because of that and complain about the RC being messy? I mean, I can handle it if there are real issues to be fixed, and I had planned to cancel the VOTE anyways to make some more adjustments but something like that is just ridiculous. Just take a look at some other published commons releases and count the number of RAT errors, even for source files. Thomas > > There is also the issue of the possibly wrong revision being tagged or > being used in the VOTE email thread. That can be fixed for RC2 as well. > > Gary > > On Mon, Nov 9, 2015 at 2:37 PM, Thomas Neidhart <thomas.neidh...@gmail.com> > wrote: > >> 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) >> >> 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 >> >> KEYS: >> https://www.apache.org/dist/commons/KEYS >> >> Please review the release candidate and vote. >> >> This vote will close no sooner that 72 hours from now, i.e. after 2300 >> GMT 12-November 2015 >> >> [ ] +1 Release these artifacts >> [ ] +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
[VOTE] Release Commons Collections 3.2.2 Based on RC1
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) 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 KEYS: https://www.apache.org/dist/commons/KEYS Please review the release candidate and vote. This vote will close no sooner that 72 hours from now, i.e. after 2300 GMT 12-November 2015 [ ] +1 Release these artifacts [ ] +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