MLE-30953 MLE-30952 MLE-30968 Vulnerability fixes

[jonmille]

https://progresssoftware.atlassian.net/browse/MLE-30953: Bumped kotlin from 2.2.21 to 2.4.0 to resolve OpenTelemetry Java v1.41.0 vuln.
https://progresssoftware.atlassian.net/browse/MLE-30952: Bumped Logback from v1.5.32 to v1.5.37
https://progresssoftware.atlassian.net/browse/MLE-30968: Bumped jacksonVersion from 2.21.1 to 2.22.0

[Copilot]

Pull request overview

Updates dependency versions/constraints in the Gradle build to address reported vulnerabilities in the Java client library build.

Changes:

• Bump logbackVersion in gradle.properties.
• Add Gradle resolutionStrategy.force entries to pin OpenTelemetry API/context versions.

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated 1 comment.

File	Description
gradle.properties	Updates the shared Logback version property used by modules/tests.
build.gradle	Forces specific OpenTelemetry artifact versions during dependency resolution to mitigate CVEs.

[rjrudin]

Couple things here - first, I recommend only declaring top-level items like this when they apply to multiple subprojects. It's a convenience, which makes sense for something that is widely used like commons-lang3.

Second - I checked the dependencies of every subproject, and it looks like opentelemetry only appears as a dependency of ml-development-tools. But it's a dependency of the "swiftExportClasspathResolvable" configuration. I didn't know what that it is, but a quick check with Copilot seemed to confirm that this doesn't impact the ml-development-tools plugin - i.e. a user of that plugin won't see the opentelemetry library in their list of dependencies when running ./gradlew buildEnvironment.

I would then first start with seeing if I can bump up the org.jetbrains.kotlin.jvm plugin version to see if that bumps up the OT library. If not, then force a newer version in the ml-development-tools build.gradle file - but definitely add a comment explaining that it's not an actual runtime dependency.

[jonmille]

I followed your recommendations and updated the Kotlin version from 2.2.21 to 2.4.0 and the OpenTelemetry Java dependency was no longer present, fixing the reported vulnerability.

[rjrudin]

I would drop the kotlin-stdlib bump and add the OkHttp bump, along with the Jackson and Logback bumps. The Jackson bump looks safe - though I would also plan on doing that in ml-gradle and Spark / Flux soon too, as we use Jackson in a lot of places.

[rjrudin]

This one is a bit tricky. This plugin (regrettably, IMO) uses Kotlin code. But OkHttp (sadly) depends on Kotlin as well. OkHttp 5.3.2 depends on kotlin-stdlib 2.2.20 and the recent 5.4.0 release (which I recommend upgrading to) depends on kotlin-stdlib 2.2.21.

Ideally, OkHttp would be on the latest kotlin-stdlib release, but it's not. For that reason, I would not bump this up. I think you can safely bump up the Gradle plugin as that only impacts the build process. But for runtime, I think we want to stick with 2.2.20 (or 2.2.21 after updating OkHttp) so that we don't risk any incompatibilities between OkHttp and kotlin-stdlib 2.4.0.