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?
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2016-01-14
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:
(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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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.
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
Last edit: pchitnis 2015-12-07
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
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
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
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
I see that the jung-3d package isn't present on GitHub. We had to drop that due to license issues with
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?
I'm waiting for this too.
(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.
Do you plan to make JUNG 2.1 available through Eclipse Orbit too ?
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. :)
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.