You watch out :p Martijn mentioned it in his mail: (as you may have noticed, there's an deserialization issue with commons-collections). And here is the answer: https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Nov 10, 2015 at 11:18 PM, Tobias Soloschenko < [email protected]> wrote: > Hi, > > please watch out - there is a security issue mentioned at heise.de (zero > day exploid) which affects common collections: > > org/apache/commons/collections/functors/InvokerTransformer.class > > Here is an article in english which mentions that issue: > > http://www.infoq.com/news/2015/11/commons-exploit > > kind regards > > Tobias > > > Am 10.11.2015 um 22:37 schrieb Martin Grigorov <[email protected]>: > > > > +1 to keep the dependency > > > > I've also took a look at the code and it seems we will need to copy quite > > some classes. > > It seems the introduction of commons-fileupload and commons-io as > > dependencies in 7.0.0 didn't lead to any complains so far. > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Mon, Nov 9, 2015 at 10:34 AM, Martijn Dashorst < > > [email protected]> wrote: > > > >> One of the problems we ran into while fixing 6021 was the ability to > >> use a Linked[Hash]Map. The default JDK version doesn't have any public > >> or protected API to give us the previous and next entries. We need > >> those to retrieve the next element when removing a child from a markup > >> container. > >> > >> Unfortunately the JDK collections don't have any extensibility that > >> would allow us to graft those missing methods upon the existing > >> collections. > >> > >> Commons Collections provides a LinkedMap class that does give us those > >> methods. Unfortunately this forces us to add a core dependency, or we > >> should copy the specific code into our project. > >> > >> Adding a dependency is bad because it adds more stuff to track--not > >> just for us, but for our users as well--, provides additional > >> headaches (as you may have noticed, there's an deserialization issue > >> with commons-collections). > >> > >> Moving the code from com-col to Wicket is also bad, as we take on the > >> maintenance burden, the code in question takes about 30-ish classes to > >> copy, and we duplicate code that is available from elsewhere > >> (duplication is bad mkay) > >> > >> Emond's suggestion is to move the code, strip it of all that we don't > >> need and maintain that ourselves. I'd like to add that we should make > >> that code package private or name it such that it doesn't conflict > >> with com-col on a class name base. > >> > >> But before we go on that path, we'd like to hear if folks have better > >> ideas? > >> > >> Martijn > >> >
