Jira Software 7.x apache-commons-compress runtime dependencies

Jira Development Jira Server
,
1

Hi,

Our plugin works on Jira Software, including versions 7.x, 8.x, and 9.x. We are trying to upgrade org.apache.commons:commons-compress:1.21 library due to security reasons. It is currently included as compile-scoped dependency in our pom.xml. This vulnerability is fixed in 1.26.x versions and as a solution, we are trying to use version 1.26.2 in pom.xml as provided-scoped. This solution works fine for the Jira Software versions 8.x and later.

But for the Jira Software 7 one of our plugins functionality that depends on this library is broken due to the following error: Caused by: java.lang.NoClassDefFoundError: org/apache/commons/compress/utils/InputStreamStatistics

We understand that Jira Software 7.x run time environment uses older commons-compress library versions. Regarding that we add the latest version 1.26.2 with compile scope to pom.xml, this time AMPS banned dependency validation fails for the following libraries commons-io:commons-io and org.apache.commons:commons-lang3. Even if we configure these dependencies as banningExcludes in the jira-maven-plugin configuration, mvn install step passes but the plugin is not installed successfully.

Is it possible to add org.apache.commons:commons-compress:1.26.2 dependency to the Jira Software 7.x Run Time dependencies, or do you have any other solution recommendation for the Jira Software 7.x versions?

Thanks,

2

What you’ve already tried is basically all that you can do.

Regardless, for every major version we recommend different versions of plugins, the major versions are breaking change versions. We don’t support cross-major compatibility.

We’re slowly removing these libraries from our API to make this kind of problem less painful, but that won’t help you for old versions.

ICYMI Jira 7 and Jira 8 are unsupported. 7 for a long time.

3

@mkemp thanks for your answer.

As a workaround solution, we successfully ran our plugin in Jira 7.x versions with some additional config changes using banningExcludes. What kind of potential impacts could have, excluding the dependencies using banningExcludes which I wrote in my previous question?

4

The biggest thing to be aware of is that Jira API might use commons compress. If you compile scope the dependency then you won’t be able to use that API since it’s two different classes to the JVM (this is how OSGi works). A much more complex problem is it’s both compile scope and imported via OSGi, this very rarely works if the versions are different as some classes might be from a newer version and some from an older version making the library break at runtime.