You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Thomas Neidhart <th...@gmail.com> on 2015/11/09 23:37:05 UTC
[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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
Posted by Stefan Bodewig <bo...@apache.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
Posted by Thomas Neidhart <th...@gmail.com>.
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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
Posted by Luc Maisonobe <lu...@spaceroots.org>.
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 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks,
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Nov 11, 2015 1:56 AM, "Thomas Neidhart" <th...@gmail.com>
wrote:
>
> On 11/10/2015 11:41 PM, Gary Gregory wrote:
> > On Tue, Nov 10, 2015 at 2:22 PM, Thomas Neidhart <
thomas.neidhart@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
Posted by sebb <se...@gmail.com>.
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 Neidhart <th...@gmail.com> wrote:
> On 11/10/2015 11:41 PM, Gary Gregory wrote:
>> On Tue, Nov 10, 2015 at 2:22 PM, Thomas Neidhart <th...@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 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
Posted by Thomas Neidhart <th...@gmail.com>.
On 11/10/2015 11:41 PM, Gary Gregory wrote:
> On Tue, Nov 10, 2015 at 2:22 PM, Thomas Neidhart <th...@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 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Nov 10, 2015 at 2:22 PM, Thomas Neidhart <th...@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.neidhart@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Posted by Thomas Neidhart <th...@gmail.com>.
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 <th...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1
Posted by Gary Gregory <ga...@gmail.com>.
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 <th...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
[CANCEL][VOTE] Release Commons Collections 3.2.2 Based on RC1
Posted by Thomas Neidhart <th...@gmail.com>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org