Maven POM for opentelemetry-exporter-sender-okhttp (and possibly others) doesn't retain transitive dependency version overrides from BOMs

[michalmela]

Describe the bug
Maven POM for opentelemetry-exporter-sender-okhttp resolves a dependency to okio to the default 3.2.0 (as okhttp 4.11 depends on) instead of the okio BOM version declared in opentelemetry gradle build files.

Steps to reproduce

1. Have the opentelemetry artifacts in the local maven repository
2. Run: mvn -f ~/.m2/repository/io/opentelemetry/opentelemetry-exporter-sender-okhttp/1.31.0/opentelemetry-exporter-sender-okhttp-1.31.0.pom dependency:tree

Alternatively:

echo '<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>minimal-pom</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencies>
  <dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-exporter-sender-okhttp</artifactId>
    <version>1.31.0</version>
    <scope>runtime</scope>
  </dependency>
</dependencies>
</project>' > pom.xml
mvn dependency:tree

What did you expect to see?

[INFO]       +- com.squareup.okio:okio:jar:3.6.0:runtime
[INFO]       |  \- com.squareup.okio:okio-jvm:jar:3.6.0:runtime

– because the opentelemetry gradle dependency management file declares a dependency on the relevant BOM in version 3.6.0

What did you see instead?

[INFO]       +- com.squareup.okio:okio:jar:3.2.0:runtime
[INFO]       |  \- com.squareup.okio:okio-jvm:jar:3.2.0:runtime

What version and what artifacts are you using?
opentelemetry-exporter-sender-okhttp:3.6.0

Environment
Runtime: OpenJDK Runtime Environment Zulu17.44+15-CA (build 17.0.8+7-LTS)
OS: OS X Sonoma

Additional context
I'd stumbled upon this issue due to OWASP dependency check reporting CVE-2023-3635 wrt okio 3.2.0 . As I tried to find out whether a newer opentelemetry-java artifacts would've bumped the okio dependency, I've seen the aforementioned BOM declaration, leading me to believe it was intended to make opentelemetry use a properly newer version of okio already.

I guess it's an issue with Gradle not including the <dependencyManagement> part in the generated POM file. If that's the case and it was not in any way intended, I could take a stab at providing a fix PR, but would first like to pick a project maintainer's mind about the issue (perhaps some guidelines, if any).

[trask]

hi @michalmela! check out #5637 (comment) and let us know if this is the same, thx

[michalmela]

Hi @trask! Thank you and sorry, I couldn't find this issue previously. It is related but focuses on sth different (the CVE itself vs dependency management), but if the problem I described here was solved, the other issue would also have a better resolution.

opentelemetry gradle build files do properly define a dependency on the newer okio BOM (i.e. without the vulnerability in question) and when running gradlew dependencies for opentelemetry-java/exporters/sender/okhttp we can see that gradle resolves the newer version:

runtimeClasspath - Runtime classpath of source set 'main'.
...
|    +--- com.squareup.okio:okio-bom:{strictly 3.6.0} -> 3.6.0

– instead of the 3.2.0 version as resolved when using opentelemetry libs as a maven artifact.

If gradle could be made to retain the okio-bom in the resulting maven artifact's pom.xml by adding a <dependencyManagement> block, I think it would make the opentelemetry (when used as a dependency) also pull in the proper, newer version of okio. WDYT?

[jack-berg]

This comment contains the reason we can't (maybe shouldn't?) do that:

We've verified that the non-vulnerable okio version works within opentelemetry's usage patterns of okhttp (since the opentelemetry-java tests themselves are running against the non-vulnerable okio version via the okio-bom usage).
But if we pass along these non-aligned versions of okhttp and okio as transitive dependencies, we could potentially break people downstream who are using okhttp in other ways.

[trask]

#5921 🎉

[jack-berg]

Resolved in #5921.