Repository navigation
Drop github.com/docker/docker via org-controlled dktest fork - #66
Merged
Merged
Conversation
github.com/docker/docker carries five advisories that no version bump can clear: the module path stopped publishing at v28.5.2 (which we already had) when the project renamed to github.com/moby/moby/v2, so the Go vuln DB records them as `introduced: 0` with no fixed event. Trivy suggests a fix at 29.3.1, but that is the Docker project release number and is not resolvable on this module path -- `go get` rejects it as an unknown revision. Nothing in the shipped binary reaches this code; govulncheck reports zero reachable vulnerabilities either way. It is imported only by dktesting, which is used exclusively from _test.go files. The cost is manifest-level: SCA tooling (BlackDuck Polaris, trivy) flags all five regardless of reachability. Upstream hit the same problem and migrated their own test harness off it in 3add8f4. The only remaining requirement was dhui/dktest, whose latest release (v0.4.6) still imports docker/docker. dhui/dktest#53 migrates it to github.com/moby/moby and is open but unmerged, so this points the requirement at our own fork of that branch, pinned to the exact commit. It needs no new dependencies: moby/moby/api v1.54.2 and moby/moby/client v0.4.1 are the versions this module already used, and neither path is flagged -- the advisories name the github.com/moby/moby root module, not those subpaths. Trivy manifest findings go from 5 to 1; what remains is the x/crypto openpgp advisory, which has no fix on any version and stays only because x/crypto is in the module graph. The openpgp package itself is no longer imported. Revert this replace once dhui/dktest#53 ships a tagged release. Note that replace directives are ignored by downstream consumers, so this affects only builds and scans of this repository. Verified: go build, go vet (which type-checks every _test.go, where dktesting is consumed), and the non-docker test packages all pass.
Coverage Report for CI Build 35296949798Coverage remained the same at 52.649%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Removes
github.com/docker/dockerfrom the dependency graph. Trivy manifest findings go 5 → 1.Why a bump can't fix this
docker/dockercarries five advisories, and none are clearable by upgrading:The module path stopped publishing at
v28.5.2when the project renamed tohub.lumenfield.work/moby/moby/v2, so the Go vuln DB records these asintroduced: 0with no fixed event. Trivy reports a fix at29.3.1, but that's the Docker project release number and isn't resolvable on this module path. Upstream hit the same wall and migrated their own harness off it in3add8f4("BlackDuck Polaris findings").Reachability vs. manifest
Worth being precise, because these disagree and both matter:
docker/dockeris imported only bydktesting, which is consumed exclusively from_test.gofiles, so it's never linked into the CLI or library.This PR is purely about the second. The shipped artifact is unchanged.
What changed
The last thing requiring
docker/dockerwasdhui/dktest, whose latest release (v0.4.6) still imports it. dhui/dktest#53 migrates dktest tohub.lumenfield.work/moby/mobybut is open and unmerged, so this points the requirement at our own fork of that branch, pinned to the exact commit:Adds no new dependencies:
moby/moby/api v1.54.2andmoby/moby/client v0.4.1are the versions this module already used. Neither is flagged — the advisories name thehub.lumenfield.work/moby/mobyroot module, not those subpaths.Result
docker/dockerCVE-2026-41567docker/dockerCVE-2026-42306docker/dockerCVE-2026-33997docker/dockerCVE-2026-41568x/cryptoGO-2026-5932The remaining one has no fix on any version and stays only because
x/cryptois in the module graph; theopenpgppackage itself is no longer imported (removed in #65).Verification
go build ./...andgo vet ./...clean.vettype-checks every_test.go, which is precisely wheredktestingis consumed, so the moby API migration is confirmed source-compatible across all 15 driver test files.go list -m github.com/docker/docker→not a known dependency.Follow-up
Revert the
replaceonce dhui/dktest#53 ships in a tagged release.replaceis ignored by downstream consumers, so this affects only builds and scans of this repository — it imposes nothing on anyone importingmigrate.Not included in
v1.0.11, which was tagged from6fa6bab: this is test-infrastructure only and does not change the released artifact.🤖 Generated with Claude Code