This module still imports github.com/docker/docker, which was deprecated in Docker Engine v29.0.0 in favour of github.com/moby/moby/client and github.com/moby/moby/api.
As noted in the v29.0.0 release notes:
The Go module github.com/docker/docker is deprecated in favor of github.com/moby/moby/client and github.com/moby/moby/api.
Because docker/buildx has not yet migrated, any Go project that transitively depends on docker/buildx (e.g. via testcontainers-go/modules/compose) is forced to carry github.com/docker/docker in its module graph. This is now causing security scanner alerts for CVE-2026-34040 and CVE-2026-33997, both fixed in moby/moby v29.3.1+ but only accessible via the new module path.
The dependency chain I'm currently facing issues with is for github.com/docker/docker v28.5.2+incompatible:
testcontainers-go/modules/compose
└─ docker/compose/v5/pkg/compose
└─ docker/buildx/store/storeutil
└─ docker/buildx/store
└─ github.com/docker/docker
There is no workaround available to downstream consumers — a replace directive cannot bridge a module path rename, and github.com/docker/docker stops at v28 on the Go module proxy.
Are there plans to migrate this module to use github.com/moby/moby/client and github.com/moby/moby/api instead of github.com/docker/docker, so that downstream projects can resolve these CVEs ?
This module still imports github.com/docker/docker, which was deprecated in Docker Engine v29.0.0 in favour of github.com/moby/moby/client and github.com/moby/moby/api.
As noted in the v29.0.0 release notes:
Because docker/buildx has not yet migrated, any Go project that transitively depends on docker/buildx (e.g. via testcontainers-go/modules/compose) is forced to carry github.com/docker/docker in its module graph. This is now causing security scanner alerts for CVE-2026-34040 and CVE-2026-33997, both fixed in moby/moby v29.3.1+ but only accessible via the new module path.
The dependency chain I'm currently facing issues with is for
github.com/docker/docker v28.5.2+incompatible:There is no workaround available to downstream consumers — a replace directive cannot bridge a module path rename, and github.com/docker/docker stops at v28 on the Go module proxy.
Are there plans to migrate this module to use github.com/moby/moby/client and github.com/moby/moby/api instead of github.com/docker/docker, so that downstream projects can resolve these CVEs ?