Dependencies: commons-configuration and commons-lang

[RockefellerA]

Hello,
I'm using ESAPI and am also using whitesource/Mend, which is flagging two dependencies ESAPI has: commons-configuration and commons-lang. These have new versions, commons-configuration2 and commons-lang3.

I've done a little research and it looks like the owasp Java Encoder is compatible with commons-lang3, but I wasn't sure if the main ESAPI project is fully compatible. I couldn't find any information on whether commons-configuration2 was compatible.

Are these planned to be updated in the future, or are there some workarounds you'd suggest? Thank you for your time!

[jeremiahjstacey]

Tracking this through maven, I believe it's more accurate to say that replacement dependencies are available. ESAPI is using the latest versions available for both commons-configuration and commons-lang.

Library dependencies are candidates for updates, so long as no existing capability is lost or otherwise negatively impacted.

There is a normal update process for any dependency that has a newer version, or for dependencies which have CVE's listed in the NVD Database. So far as I can tell neither of these conditions is true for either of the listed artifacts.

There does not appear to be any issues created to perform the conversion to either of the newer dependencies you've referenced, but I believe that would be the most likely course. Generate a task in the project identifying the potential for dependency replacement.

You are also welcome, and encouraged, to create a fork and try it out.

These are the links I used for reference:
NVD commons-configuration
Maven Central commons-configuration

NVD commons-lang
Maven Central commons-lang

If you would like to try to "work around", you can make the attempt to replace these dependencies by using exclude clauses in your pom for the two projects of interest, then specifically include the replacements you'd like to try. If the API's are an exact match, it might work, but I'm not sure I'd have very high expectations.
Dependency Exclusions

[jeremiahjstacey]

I tried doing a flat-out replacement of the dependencies in ESAPI, and the project does not compile as-is. I did not do much digging into the 'why', but it's worth noting that this conversion may take some scale of effort, and the "work around" I posted above cannot work.

These are the dependency references I used.

<dependency>
	<groupId>com.melloware</groupId>
	<artifactId>commons-configuration2</artifactId>
	<version>2.8.1</version>
</dependency>
<dependency>
	<groupId>org.apache.commons</groupId>
	<artifactId>commons-lang3</artifactId>
	<version>3.12.0</version>
</dependency>

[kwwall]

@RockefellerA wrote:

Hello, I'm using ESAPI and am also using whitesource/Mend, which is flagging two dependencies ESAPI has: commons-configuration and commons-lang. These have new versions, commons-configuration2 and commons-lang3.

I've done a little research and it looks like the owasp Java Encoder is compatible with commons-lang3, but I wasn't sure if the main ESAPI project is fully compatible. I couldn't find any information on whether commons-configuration2 was compatible.

I can't comment on the OWASP Java Encoder Project. You'd have to ask them.

Are these planned to be updated in the future, or are there some workarounds you'd suggest? Thank you for your time!

To add to what @jeremiahjstacey wrote, even if no changes were required to ESAPI and all the tests passed, there are additional considerations when one is a library provider and one decides to upgrade to a newer major revision of a library (which seems to be the case for both commons-configuration2 and commons-lang3). We generally try to avoid bumping to a major revision of a dependency unless there is good reason to. Some of those valid reasons might be:

• It's the only way to pick up a security patch in a dependency where there is a vulnerability which has an exploitable path via ESAPI.
• The previous major version is no longer supported at all and the library has a long history of vulnerabilities.
• It is a 'provided' library that doesn't need to be distributed. (We have done that at various points with the Servlet API, especially when we went bumped the minimally supported JDK for ESAPI, first from Java 5 to Java 6, then from Java 6 to Java 7, and recently from Java 7 to Java 8.)

But we try to be really cautious when we make that decision. Why? Well, when considered from a semantic naming perspective, bumps in a library's major # does not guarantee backward compatibility with the previous major #. In fact, worse than that, it may require extensive code changes. (E.g., compare Apache Struts 1.x to Struts 2.x.) Now one could imagine ESAPI using just a class or 2 from a dependent library (in fact, that is the case for commons-configuration, where we only use XMLConfiguration and ConfigurationException). Now lets suppose that those 2 classes have not interface changes and not changes in semantic behavior either. (Which would kind of be expected from any sort of Exception related classes.) If that were the case (and I'm not claiming it is; in fact, it may not be as per Jeremiah's findings), then ESAPI could decide move to commons-configuration2 and that wouldn't impact ESAPI behavior at all. But hang on a minute? Does that mean we should do it? Absolutely not! Why not, because what if our ESAPI clients are using other classes from (say) commons-configuration that have differences in interfaces or differences in semantics that do their commons-configuration2 counterparts? Well, that means if a client is using (say) GAV commons-configuration:commons-configuration:1.10 (which happens to be what ESAPI is currently using) and if we decided to use (say) GAV com.mellows:commons-configuration2:2.8.1, there would likely be changes that were forced upon our clients. (If the commons-configuration2 classes have the same package names, it definitely could case conflicts because if you have both jars in the classpath, you can't guarantee which will be loaded first. If they did it like Struts 1 --> Struts 2 where they changed the package name, they could co-exist together and would be less disruptive, but at the expense of forcing code changes to their clients when they decide to move from one to the other.) I haven't really investigated either nor do I intend to at this point. It is not a pressing need at the moment. If you would like to do the research and find they are different package names for each of the 2 libraries you proposed we transition to, come back here and let us know and at least we can all have a more fully informed discussion. But until I know that, moving to these versions except when we bump from ESAPI 2.x to ESAPI 3.x is not very likely unless one of those extenuating circumstances that I previously mentioned arises.

This is why you might here library developers take the "if it ain't broke, don't fix it" approach. It's not that we are lazy, but rather, we're just trying to watch out for our clients best interests.

Hope that makes sense. If not, please ask questions so I can try to clarify our position.

[RockefellerA]

Thank you for your response (And @jeremiahjstacey as well, I could only pick one answer to highlight!), this makes perfect sense and I suspected as such, but I wanted to see if it was 'in the cards' for any reason. The bugs flagged by Whitesource/Mend are things we can probably safely ignore, and I believe both libraries can coexist in our code since they renamed the packages - and I wouldn't want to force code changes downstream on anyone else using ESAPI if there wasn't an actual need for it.