-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Would you consider upgrading gate-core from JDOM 1.1.3 to JDOM 2.0.6? #149
Comments
In theory I can't see any reason why we shouldn't move to the latest JDOM assuming someone has the time to do so given the namespace changes. We'd also have to double check exactly where JDOM might be exposed as part of the public API as changing the namespace might also effect plugins compiled against GATE. |
A cursory search of the GateNLP GitHub namespace suggests there's half a dozen or so of our own plugins that make use of JDOM, plus an unknown number of third party ones. All of these would need an update if gate-core moved, if only to add their own direct dependency on JDOM rather than relying on it as a transitive. More generally though, this opens up a question about plugins making use of "accidental" transitive dependencies. Recent versions of Gradle split the "compile" scope and make a distinction between |
It certainly seems like a good idea to separate api and implementation dependencies. But just because a library isn’t exposed by an API doesn’t guarantee that a vulnerability in the library isn’t exploitable by nefarious and clever means. My concern is having to explain to clients who uncover vulnerabilities by scanning JAR files that there is no path by which untrusted (i.e. XML) data can be fed to JDOM, for instance. I’m just very sensitive to JDOM because it is widely used and has to be mitigated in many libraries that we use. On a related note, thanks for moving away from Log4j in Gate 9.0. Similar issues there with Log4j 1.x that we had to explain away. |
This issues just came up again via the mailing list. Whilst we don't yet have a fix in place it's worth repeating the comment @ianroberts made that
|
While it's not likely to be exploitable, CVE-2021-33813 has been published against JDOM through version 2.0.6, which is the latest version. Although there is not currently a version of JDOM 2 that is provably immune to XXE, at least version 2.0.6 has a security framework similar to XStream's that allows a caller to prevent entity expansion. Upgrading from jdom 1.1.3 to jdom 2.0.6 would put gate-core in a good position to support newer versions of jdom that have the security vulnerability fixed. (There is a new version; however, the maintainers of jdom are no longer able to publish it to the Sonatype repo--which is a long sad saga.). Unfortunately, there are namespace changes between versions 1 and 2 of jdom, so code updates and recompiles are required.
The text was updated successfully, but these errors were encountered: