Security issue with collections-generic lib in jung

[pchitnis]

Hi dev team,

The jung-algorithms jar has a transitive dependency on the jar net.sourceforge.collections:collections-generic:jar. I recently came to know about the deserialization vulnerability in the commons-collection lib. It seems that the collections-generic lib also has the culprit class InvokerTransformer. So my question here is I think this security issue would be applicable to this collections-generic lib as well since it has that culprit class? Can we have this issue fixed for the collections-generic lib? If yes, how early we can have it?

Refer below links for more info on this vulnerability –
https://blogs.oracle.com/security/entry/security_alert_cve_2015_4852
https://issues.apache.org/jira/browse/COLLECTIONS-580

Thanks much.

-Pooja

[Joshua O'Madadhain]

Pooja:

Thanks for bringing this to our attention.

The bad news: we don't own collections-generic and I suspect that it's no longer being updated. (Nor do we especially want to own a fork of it.)

The news: JUNG itself does not use InvokerTransformer anywhere, so I don't believe that there are any immediate security implications for JUNG users, as long as they aren't using InvokerTransformer themselves (or using some other library that does).

The good news: we're in the process of finishing up JUNG 2.1 over on GitHub (I'll send a formal announcement out soon), and it uses Google's Guava libraries internally in place of collections-generic. You can get it here: https://github.com/jrtom/jung
(What remains is mostly housekeeping: adding links in various places, uploading pre-built jars, tweaking Maven POMs, etc. The code is complete.)

Hope that addresses your concern. Please let us know if you have any questions.

Joshua O'Madadhain

[pchitnis]

Hi Joshua,

Thanks for quick response.
The good news mentioned above is a great news !
My next question is how early the JUNG 2.1 will be generally available?

-Pooja

[Joshua O'Madadhain]

JUNG 2.1 should be formally released within a few weeks, I hope. Certainly by sometime in January 2016.

In the meantime, as noted in my response above, you can already get and build the code with the source and build files available on GitHub.

Joshua O'Madadhain

[Anonymous]

Glad to hear about the new release and move to GitHub!

FYI, the Debian-Med team has a package of Jung in progress right now; we made a patch to replace the unofficial Collections 1.5 and the official Apache Collection 4 release:

http://anonscm.debian.org/cgit/debian-med/libjung-java.git/tree/debian/patches/use-apache-commons-collections
Followed by a general transformation in
http://anonscm.debian.org/cgit/debian-med/libjung-java.git/tree/debian/rules

xargs sed -i -e \ 's/org.apache.commons.collections15/org.apache.commons.collections4/' \ -e 's/org.apache.commons.collections4.Buffer/java.util.Queue/' \ -e 's/org.apache.commons.collections4.buffer.UnboundedFifoBuffer/java.util.LinkedList/' \ -e 's/UnboundedFifoBuffer/LinkedList/' \ -e 's/Buffer</Queue<>getInstance/CloneTransformer.cloneTransformer/' \ -e 's/OrPredicate.getInstance/OrPredicate.orPredicate/' \ -e 's/TruePredicate.getInstance/TruePredicate.truePredicate/' ;

I see that the jung-3d package isn't present on GitHub. We had to drop that due to license issues with

./jung-3d-2.0.1-sources/edu/uci/ics/jung/visualization3d/control/*

• You acknowledge that this software is not designed, licensed or
• intended for use in the design, construction, operation or
• maintenance of any nuclear facility.

This restriction on use violates the Debian Free Software Guidelines so I'm dropping it from Debian for now.

Will the jung-3d package have a future release as well?

[Mark Hale]

I'm waiting for this too.

[Joshua O'Madadhain]

(SourceForge's RSS feed is busted, I'm still not seeing these posts in a timely fashion. sigh.)

Responding to the questions re: jung-3d: we do not have any plans to release any future versions of it, no. It was an experiment that we never fully invested in, and we don't have the resources to invest in it further now. As you noted, it's not part of the new version that's on GitHub and should be available via Maven soon.

JUNG 2.1 also does not include a dependence on the Colt matrix libraries, which transitively entailed their own somewhat odd licensing requirements.

We still hope to get JUNG 2.1 released by the end of January.

[Kristof Szabados]

Do you plan to make JUNG 2.1 available through Eclipse Orbit too ?

[Joshua O'Madadhain]

Kristof, we were contacted last year by someone representing Eclipse about distributing JUNG, and at that time we worked things out so that they could do so. I assume that this was done under the Orbit effort, although that name was not mentioned.

I don't see any sign that they've done so up to this point: http://download.eclipse.org/tools/orbit/downloads/drops/R20151221205849/
but the ball is in their court.

That said, Eclipse Orbit doesn't seem to be prioritizing keeping track of new releases: the latest version of Guava that's included in Orbit is 15.0, which was released about 2.5 years ago.

So if you're interested in JUNG 2.1 (and future versions) being released through Eclipse, we encourage you to contact them and suggest it; we're happy to work with Eclipse if they ask for it. I don't personally have the spare cycles to manage that process right now.

Incidentally, JUNG 2.1-SNAPSHOT is now available via Maven on Sonatype: https://oss.sonatype.org/content/repositories/snapshots/net/sf/jung/

and the formal release should be happening Real Soon Now. :)

[Joshua O'Madadhain]

JUNG 2.1 has now been formally released on GitHub: https://github.com/jrtom/jung/releases/tag/jung-2.1
and is available via Maven, instructions here: https://github.com/jrtom/jung/blob/master/README.md

Thanks for your patience, and we look forward to seeing you over at GitHub.