Upgrades dependencies to use newer, non-vulnerable versions or more tightly scoped Gradle configurations where applicable. In order to minimize the scope of this change, dependencies were only updated for projects that had dependencies flagged by the snyk test command
The most significant refactor is of the testing-common project. Specifically, Jetty 8 is old enough that there are vulnerabilities that will only be fixed in newer major versions. This isn't particularly a problem though, as this java-library is not published externally. We restrict the snyk test command to only look for dependencies on the runtimeClasspath. In order to make it more clear the intention of this project, I refactored it to use the java-test-fixtures plugin and changed the scope of the dependencies used in the project to only be on the testFixturesRuntimeClasspath resulting in a better separation of testing dependencies from runtime dependencies. This allows us to safely keep using Jetty 8 without worrying about accidentally including it in a release in the future.
Testing
The risk of the testing-common changes affecting a production release is very small, since it is only consumed by the testImplementation configuration in other projects. The AutoService upgrades are best checked by our smoke tests across various runtimes/application servers, but i also manually verified that contents of META-INF/services/io.opentelemetry.javaagent.tooling.InstrumentationModule was the same.
I think riskiest change was the upgrade of protobuf-java-util from 3.11.4 to 3.15.8. Based on our smoke tests that interact with the otel collector/backend which receive messages serialized/deserialized with this util, I feel pretty confident. But, I'm not an expert with protobuf so if there's any "gotchas" that I should look for I'm happy to chase them down
Here's the snyk vulnerability report
Testing /Users/rdens/git/hypertrace/javaagent...
Tested 24 dependencies for known issues, found 1 issue, 1 vulnerable path.
Issues to fix by upgrading:
Upgrade com.google.protobuf:protobuf-java-util@3.11.4 to com.google.protobuf:protobuf-java-util@3.15.0 to fix
✗ Information Disclosure [Medium Severity][https://snyk.io/vuln/SNYK-JAVA-COMGOOGLEGUAVA-1015415] in com.google.guava:guava@28.1-android
introduced by com.google.protobuf:protobuf-java-util@3.11.4 > com.google.guava:guava@28.1-android
Organization: hypertrace
Package manager: gradle
Target file: build.gradle.kts
Project name: javaagent/javaagent-core
Open source: no
Project path: /Users/rdens/git/hypertrace/javaagent
Licenses: enabled
Checklist:
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] Any dependent changes have been merged and published in downstream modules
Documentation
N/A
Links
https://snyk.io/vuln/SNYK-JAVA-COMGOOGLEGUAVA-1015415
We weren't using guava in any significant way on the runtime classpath, so there's no significant exploit risk here. But, we definitely should still update it.
Description
Upgrades dependencies to use newer, non-vulnerable versions or more tightly scoped Gradle configurations where applicable. In order to minimize the scope of this change, dependencies were only updated for projects that had dependencies flagged by the
snyk testcommandThe most significant refactor is of the
testing-commonproject. Specifically, Jetty 8 is old enough that there are vulnerabilities that will only be fixed in newer major versions. This isn't particularly a problem though, as thisjava-libraryis not published externally. We restrict thesnyk testcommand to only look for dependencies on theruntimeClasspath. In order to make it more clear the intention of this project, I refactored it to use thejava-test-fixturesplugin and changed the scope of the dependencies used in the project to only be on thetestFixturesRuntimeClasspathresulting in a better separation of testing dependencies from runtime dependencies. This allows us to safely keep using Jetty 8 without worrying about accidentally including it in a release in the future.Testing
The risk of the
testing-commonchanges affecting a production release is very small, since it is only consumed by thetestImplementationconfiguration in other projects. The AutoService upgrades are best checked by our smoke tests across various runtimes/application servers, but i also manually verified that contents ofMETA-INF/services/io.opentelemetry.javaagent.tooling.InstrumentationModulewas the same.I think riskiest change was the upgrade of
protobuf-java-utilfrom3.11.4to3.15.8. Based on our smoke tests that interact with the otel collector/backend which receive messages serialized/deserialized with this util, I feel pretty confident. But, I'm not an expert with protobuf so if there's any "gotchas" that I should look for I'm happy to chase them downHere's the snyk vulnerability report
Checklist:
Documentation
N/A
Links