Question

Userlib: duplicate and conflicting JAR files, clean-up and CVEs

2

Question: Does anybody have a good idea or solution to deal with the duplicate JAR files with different naming and versions in the userlib folder and CVE’s in these libraries? We now clean this folder manually which cost a lot of time and I am looking for a better solution. When you update an AppStore module you have to start over again. Has anybody have a good solution? (I think it effects all applications so maybe a more robust solution from Mendix is needed.) Some background information: When you add MxAppStore modules these module can include Java code bundled in JAR libary files. These are placed in the userlib folder. These modules often use different versions of a JAR file and often different naming conventions. When starting an application, Java randomly choses which JAR file to use in case of duplicate JAR files. This can create random errors after a restart or the use of outdated (insecure) javacode. The most common naming convention is <maven artifact-id>-<version>.jar (commons-compress-1.21.jar). But sometimes other conventions are used like: <maven group-id>.<maven artifact-id>-<version>.jar (com.springsource.org.apache.commons.logging-1.1.1.jar) or <maven artifact-id>-<version>-<maven classifier>.jar (guava-30.0-jre.jar). Some conflicts in my userlib folder: commons-compress-1.21.jar and commons-compress-1.19.jar are both present. com.springsource.org.apache.commons.logging-1.1.1.jar and commons-logging-1.2.jar are present. org.apache.commons.commons-compress-1.19.jar and commons-compress-1.21.jar are present. A trickier one is the activation and activation api. It is present in many forms: jakarta.activation-api-1.2.1.jar, com.springsource.javax.activation-1.1.1.jar, activation-1.1.1.jar. In bouncy castle somebody forgot the dot in the version 167: bcpkix-jdk15on-167.jar <-> bcpkix-jdk15on-1.69.jar Some of these libraries contain security leaks. They need to be updated. Eg. commons-compress-1.19.jar should be replaced with commons-compress-1.21.jar. Is an automated check available?

asked 2022-05-09

Casper Leenmans

1 answers

Ronald Catersels · Accepted Answer · 2022-05-09

Mendix is working on a sollution for the JAR hell you can end up with. But untill then I can give you some pointers how I solve these issues.

Only update one marketplace module at the time. After the import goto the userlib directory and check the changed dates of the JAR files. This give you all the files that just have changed and need to be checked out. If you already have a newer version of the JAR keep the latest and delete the older JAR(s) but keep the .Required file. This way you still have a reference that this JAR file is also used by another module. If you have an older versions of the JAR then the one you just imported delete those while keeping the .Required file of that other module. If the module is the same you can also delete the .Required file.
When moving to a higher Mx version (so from 8 to 9 for instance) I delete all the JAR files and reimport all the modules again. You probably needed to do that anyway due to the framework upgrade. Do note that if you are using JAR files of your own (so not downloaded from a marketplace module) you should offcourse keep those. But then again you probably already managed the version of that JAR file yourself.

Hope this helps a bit. Do not that there is also a github project to automaticly clean out your JAR files. See the Github page here: https://github.com/cinaq/mendix-userlib-cleaner But do use with care.

Regards,

Ronald