Context
The govulncheck step in the new ci-lint workflow fails with 4 reachable vulnerabilities in transitive dependencies. This is pre-existing dependency rot — the gate did not introduce it, it exposed it.
All four are reachable from WireguardReconciler.Reconcile — via client.subResourceClient.Update and wgtypes.GeneratePrivateKey.
All three modules are // indirect, pulled in through k8s.io/client-go v0.30.3 / sigs.k8s.io/controller-runtime v0.18.5 / k8s.io/apiserver.
Why this blocks everything
ci-lint feeds the aggregate ci check. Until this is fixed every PR in the repo fails a required check, including all of #37's phases.
The fix is contained — verified
Minimal version selection permits raising an indirect above what its parent requires, so the Kubernetes stack does not need to move:
go get google.golang.org/grpc@v1.82.1 golang.org/x/net@v0.55.0 golang.org/x/text@v0.39.0
go mod tidy
Verified locally on the #39 branch:
go.mod/go.sum only — 19 indirect module lines; k8s.io/* and controller-runtime untouched- transitively also raises otel 1.19→1.43, protobuf 1.33→1.36.11, x/crypto, x/oauth2, x/sync, x/sys, x/term, genproto
go build ./..., go vet ./... cleango test ./... passes — controller envtest suite 77s, plus ipam and iptablesgovulncheck ./... reports zero module vulnerabilities afterwards
So the larger question — whether to bring client-go/controller-runtime off the 2024-era 0.30/0.18 line — is real but separable, and should be its own issue. It is not needed to clear this gate.
Note on a pipeline fragility found while verifying
After the bump, govulncheck reports 7 findings from the Go standard library rather than from modules (crypto/tls, net/http), because the toolchain used locally was go1.26.4 and the fixes land in 1.26.5/1.26.6.
CI resolves its toolchain via setup-go with go-version-file: go.mod, so it installs the newest 1.26.x on the runner and should not see these. But it does mean the lint gate is sensitive to the runner's Go patch version: if a stdlib CVE is published before the runner image catches up, lint goes red with no code change. Worth deciding whether govulncheck should scope to modules or tolerate stdlib findings.
Acceptance criteria
Blocks #37.
Context
The
govulncheckstep in the newci-lintworkflow fails with 4 reachable vulnerabilities in transitive dependencies. This is pre-existing dependency rot — the gate did not introduce it, it exposed it.google.golang.org/grpcgolang.org/x/textgolang.org/x/netgolang.org/x/netAll four are reachable from
WireguardReconciler.Reconcile— viaclient.subResourceClient.Updateandwgtypes.GeneratePrivateKey.All three modules are
// indirect, pulled in throughk8s.io/client-go v0.30.3/sigs.k8s.io/controller-runtime v0.18.5/k8s.io/apiserver.Why this blocks everything
ci-lintfeeds the aggregatecicheck. Until this is fixed every PR in the repo fails a required check, including all of #37's phases.The fix is contained — verified
Minimal version selection permits raising an indirect above what its parent requires, so the Kubernetes stack does not need to move:
Verified locally on the #39 branch:
go.mod/go.sumonly — 19 indirect module lines;k8s.io/*andcontroller-runtimeuntouchedgo build ./...,go vet ./...cleango test ./...passes — controller envtest suite 77s, plus ipam and iptablesgovulncheck ./...reports zero module vulnerabilities afterwardsSo the larger question — whether to bring
client-go/controller-runtimeoff the 2024-era 0.30/0.18 line — is real but separable, and should be its own issue. It is not needed to clear this gate.Note on a pipeline fragility found while verifying
After the bump,
govulncheckreports 7 findings from the Go standard library rather than from modules (crypto/tls,net/http), because the toolchain used locally was go1.26.4 and the fixes land in 1.26.5/1.26.6.CI resolves its toolchain via
setup-gowithgo-version-file: go.mod, so it installs the newest 1.26.x on the runner and should not see these. But it does mean the lint gate is sensitive to the runner's Go patch version: if a stdlib CVE is published before the runner image catches up,lintgoes red with no code change. Worth deciding whethergovulncheckshould scope to modules or tolerate stdlib findings.Acceptance criteria
govulncheck ./...clean of module vulnerabilitiesk8s.io/*andcontroller-runtimeversions unchanged by this PRgo build,go vet,go mod tidy -diffand the full test suite passBlocks #37.