Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success

[agent] Found by the scheduled Go modules bug-hunt routine (ledger #317).

Summary

When a Go patch changes the patched module's own go.mod (the common security-fix shape: bump a vulnerable dependency, e.g. require example.com/dep v1.0.0 → v1.1.0, or add a new require), agent apply and vendored vendor write the directory replace to .socket/go-patches/… / .socket/vendor/golang/… and exit 0. Go reads the requirements from the replacement directory's go.mod, so the module graph changes, but the consumer's go.mod and go.sum are left as they were. Since Go 1.16 the default is -mod=readonly, so the next plain go build fails:

requirement bumped: go: updates to go.mod needed; to update it: go mod tidy
requirement added: missing go.sum entry for module providing package example.com/dep (imported by example.com/upstream)

Meanwhile apply --check / vendor --check exit 0 and vex attests not_affected.

Impact

CI (and any default go build/go test) breaks right after a "successful" apply or vendor. A user has to run go mod tidy (or build with -mod=mod), which changes go.mod/go.sum outside socket-patch's ownership. The --check audit, meant as CI's gate, doesn't catch it. Yarn has the same class of bug (#591).

Repro (agent mode, hermetic file GOPROXY, hand-staged manifest)

SP=/path/to/socket-patch
gsha(){ python3 -c 'import hashlib,sys;d=open(sys.argv[1],"rb").read();print(hashlib.sha256(b"blob %d\0"%len(d)+d).hexdigest())' "$1"; }
T=$(mktemp -d); export GOMODCACHE=$T/mc GOPROXY=file://$T/proxy GOSUMDB=off GOFLAGS=-mod=mod GOTOOLCHAIN=local GOCACHE=$T/gc
pub(){ M=$1 V=$2 D=$3; px=$T/proxy/$M/@v; mkdir -p $px $T/z/$M@$V; cp -r $D/. $T/z/$M@$V/; echo "{\"Version\":\"$V\"}">$px/$V.info; cp $D/go.mod $px/$V.mod; (cd $T/z && zip -qrD $px/$V.zip $M@$V); echo $V>>$px/list; rm -rf $T/z; }
mkdir -p $T/dep $T/up $T/c
printf 'module example.com/dep\n\ngo 1.21\n' > $T/dep/go.mod
printf 'package dep\nfunc Safe(s string) string { return "OLD-" + s }\n' > $T/dep/dep.go; pub example.com/dep v1.0.0 $T/dep
printf 'package dep\nfunc Safe(s string) string { return "FIXED-" + s }\n' > $T/dep/dep.go; pub example.com/dep v1.1.0 $T/dep
printf 'module example.com/upstream\n\ngo 1.21\n\nrequire example.com/dep v1.0.0\n' > $T/up/go.mod
printf 'package upstream\nimport "example.com/dep"\nfunc Greeting() string { return dep.Safe("PRISTINE") }\n' > $T/up/lib.go; pub example.com/upstream v1.0.0 $T/up
cp $T/up/lib.go $T/b.go; cp $T/up/go.mod $T/b.mod; sed s/PRISTINE/PATCHED/ $T/b.go > $T/a.go; sed s/v1.0.0/v1.1.0/ $T/b.mod > $T/a.mod
cd $T/c; printf 'module example.com/c\n\ngo 1.21\n\nrequire example.com/upstream v1.0.0\n' > go.mod
printf 'package main\nimport ("fmt";"example.com/upstream")\nfunc main(){fmt.Println("OUT:",upstream.Greeting())}\n' > main.go
go mod tidy && go mod download example.com/dep@v1.1.0 && GOFLAGS= go run .      # OUT: OLD-PRISTINE
mkdir -p .socket/blobs; for f in b.go a.go b.mod a.mod; do cp $T/$f .socket/blobs/$(gsha $T/$f); done
cat > .socket/manifest.json <<J
{"patches":{"pkg:golang/example.com/upstream@v1.0.0":{"uuid":"11111111-2222-4333-8444-555555555555","exportedAt":"t","files":{
 "lib.go":{"beforeHash":"$(gsha $T/b.go)","afterHash":"$(gsha $T/a.go)"},
 "go.mod":{"beforeHash":"$(gsha $T/b.mod)","afterHash":"$(gsha $T/a.mod)"}},
 "vulnerabilities":{"GHSA-gogo-patc-hes1":{"cves":["CVE-2026-5151"],"summary":"s","severity":"high","description":"d"}},"description":"","license":"","tier":""}},"setup":{"manual":["golang"]}}
J
$SP apply --offline; echo apply=$?                       # apply=0
GOFLAGS= go build ./...; echo build=$?                   # go: updates to go.mod needed ... build=1
$SP apply --check --offline >/dev/null; echo check=$?    # check=0
$SP vex --offline --product pkg:golang/example.com/c --output v.json   # statement: not_affected
GOFLAGS=-mod=mod go run .                                # OUT: FIXED-PATCHED (go.mod/go.sum rewritten by go)

Variant: a patch that adds require example.com/dep v1.0.0 (and imports it) gives missing go.sum entry for module providing package example.com/dep on the default build, with the same apply/--check exit 0.

Vendored mode: the same patched module served as a granted tarball from a mock patch service (SOCKET_VENDOR_URL=http://127.0.0.1:<port>, POST /patch/package → {"status":"granted","artifacts":[{"kind":"tarball",…,"integrity":{"sha512":…}}]}): vendor exit 0 with no warnings, default go build → updates to go.mod needed, vendor --check exit 0.

Expected vs actual

Expected: docs/ecosystems.md ("Go: directory replaces and go.sum") says the wiring is a committed replace and that "apply --check gives CI a read-only audit that the committed redirects still match the manifest". So after a successful apply/vendor the project should build with the default flags, or the CLI should refuse / warn (for example, run the equivalent of go mod tidy for the replaced module's new requirements, or report that go.mod/go.sum need updating), and --check should fail while the graph is out of sync. The docs don't list a patched module go.mod as a limitation.
Actual: exit 0, no warning, --check 0, VEX not_affected. The next default go build fails.

Matrix (Linux, main `045d7ec`, 4.0.0)

OS	go	agent (bump)	agent (add require)	vendored (bump)	hosted
Linux	1.21.13	fail	untested	untested	untested
Linux	1.22.12	fail	untested	untested	untested
Linux	1.24.7	fail (2/2)	fail	fail (2/2)	untested
Linux	1.26.8	fail	untested	untested	untested
macOS / Windows	any	untested (no probe branch; Windows is blocked by #346 anyway)

Hosted mode is untested. The service builds the replacement zip and its /go.mod hash, so the same missing requirement sync probably applies there.

Suspect code

crates/socket-patch-core/src/patch/redirect/golang_local.rs:169 (apply_go_redirect): writes the copy and the replace, but never compares the copy's go.mod requirements against the consumer graph.
crates/socket-patch-core/src/vendor/golang.rs:210 (vendor_go_module): same for the vendored tree.
crates/socket-patch-core/src/patch/redirect/golang_local.rs:452 (verify_go_redirect_state): --check only hashes the manifest's files.

No first bad version: 3.3.0 rejects this manifest shape (see the ledger).

go: run 10 ledger (#618)

[agent] Triaged as priority:p2 (Go modules). This isn't a duplicate, and no open or merged PR fixes it. I confirmed it by reading main 045d7ec. apply_go_redirect (patch/redirect/golang_local.rs) writes the copy and the replace but never reads the replacement's own go.mod. verify_go_redirect_state only cross-checks the consumer go.mod require set against the patched version and hashes the manifest files. The vendored path in vendor/golang.rs has the same gap.

Related issues that are not clustered with this one:

Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343 (vendor/modules.txt not synced) is a different sync gap with a different fix.
Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591 is the yarn classic analogue in separate code.

Generated by Claude Code

[agent] Hosted mode has the same bug, on main 045d7ec (CLI 4.0.0). I reproduced it 2 out of 2 times on go 1.24.7, and once each on 1.21.13, 1.22.12 and 1.26.8.

Setup: a local mock patch API returns view/<uuid> and a /patches/package grant with a goproxy registryOverride, in the same shape as e2e_golang_hosted_build.rs. The module proxy is served over http://. The served gopatch zip patch.socket.dev/gopatch/<uuid>@v1.0.0-socketpatch.1 keeps module example.com/upstream, and its go.mod bumps require example.com/dep v1.0.0 → v1.1.0. The consumer's tidy go.mod has require example.com/dep v1.0.0 // indirect.

get <uuid> --mode hosted --json --yes exits 0 with status: success, redirected: 1, rewrittenFiles: [go.mod, go.sum] and warnings: []. It adds the replace … => patch.socket.dev/gopatch/<uuid> v1.0.0-socketpatch.1 line and swaps the upstream go.sum pair for the gopatch pair. The example.com/dep requirement and its go.sum lines are left at v1.0.0.
A day-2 go build ./... (fresh caches, default -mod=readonly, GOFLAGS=) fails with go: updates to go.mod needed; to update it: go mod tidy on 1.21.13, 1.22.12, 1.24.7 and 1.26.8.
vex --product … exits 0 and attests not_affected ("Patched via Socket patch … (redirected)") for a project that doesn't build.

So agent, vendored and hosted all wire in the patched module's go.mod requirements without syncing the consumer's go.mod and go.sum. For hosted mode, the rewriter would also need the go.sum lines for any newly required versions (dep v1.1.0/go.mod and the zip h1:). The gopatch grant doesn't carry those today.

Generated by Claude Code

v5 release blocker (P1). When the patch changes Go requirements, the normal next build must work. Update or explicitly guide the required go.mod/go.sum refresh.

This follows the maintainer's release scope: one normally completing CLI instance, prioritizing valid-lockfile patch/install behavior, compatibility, and actionable CLI UX.

[agent] Claiming for v5 blocker burn-down (shared root cause: Go redirect wiring edits only the consumer go.mod replace; vendor/modules.txt and the consumer requirement graph/go.sum are never synced or checked). Branch: agent/v5-go-consumer-sync. Claim-ID: 2026-10-09T16:41:32Z-ccb36f

Navigation Menu

Repository navigation

Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default `go build` fails while apply, --check and VEX report success #618

Summary

Impact

Repro (agent mode, hermetic file GOPROXY, hand-staged manifest)

Expected vs actual

Matrix (Linux, main `045d7ec`, 4.0.0)

Suspect code

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success #618

Description

Summary

Impact

Repro (agent mode, hermetic file GOPROXY, hand-staged manifest)

Expected vs actual

Matrix (Linux, main 045d7ec, 4.0.0)

Suspect code

Activity

mikolalysenko commented on Oct 2, 2026

mikolalysenko commented on Oct 3, 2026

mikolalysenko commented on Oct 9, 2026

mikolalysenko commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default `go build` fails while apply, --check and VEX report success #618

Matrix (Linux, main `045d7ec`, 4.0.0)