[Bug]: update `docker-java` transitive deps

[yogurtearl]

Module

Core

Testcontainers version

1.20.4

Using the latest Testcontainers version?

Yes

Host OS

macOS

Host Arch

arm

Docker version

N/A

What happened?

testcontainers shades in docker-java and all its transitive deps.

docker-java uses old versions of deps with vulns:

• Upgrade Guava to resolve CVE-2020-8908 docker-java/docker-java#2370
• Upgrade Apache Commons Compress to resolve CVE-2024-25710 docker-java/docker-java#2369
• Upgrade Apache Commons IO to resolve CVE-2024-47554 docker-java/docker-java#2368

testcontainers should force upgrade these transitive deps to the latest commons-io, commons-compress, guava and any other shaded dep to pick up vuln fixes.

Relevant log output

Additional Information

No response

[eddumelendez]

I am closing this due to there are already issues reported for those deps #8338 #9289 #9528. This is broader than just updating deps.

[ZachChuba]

@eddumelendez Is there a specific timeline on these changes? I know in the snakeyaml case backwards compatibility was a concern, but security should take a priority over backwards compatibility. Testcontainers still uses a version of jackson-databind susceptible to a RCE. These are severe vulnerabilities compromise the security of the whole of testcontainers.

[yogurtearl]

These are shaded deps, not transitive deps, so version changes should not affect backwards compat.

i.e
org/testcontainers/shaded/com/fasterxml/jackson/databind/annotation/JacksonStdImpl.class is directly in testcontainers-1.20.4.jar with a org.testcontainers.shaded prepended to the package name.

So the only way upgrading that would break something outside of testcontainers is if a consumer was doing import org.testcontainers.shaded....., which they should not be doing.

Shading has downsides, but upgrading shaded deps without breaking consumers is one of the upsides.

As long as the testcontainer test pass, then upgrading these poses little risk to users of testcontainers.

[ZachChuba]

@yogurtearl
I'm considering implementing the broad changes required to upgrade vulnerable dependencies, testing and validating, and then opening a PR. I want to know how these vulnerabilities are impacting your organization. Are they blocking release gates?

In my organization, we're facing a block because of the mere presence of these testcontainers vulns within our SDLC, even though it's a test-only dependency with no potential presence in any release artifacts. Are you encountering similar challenges?