Vendored Go undo (vendor --revert, rollback, remove) stays silent about a stale vendor/modules.txt, so every build fails with "inconsistent vendoring"

Chiusa
  • Qualcosa non va?
#1,777 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #1778 di @mikolalysenko — integrata

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
30/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go, rust
Ambito
build-system, cli

Direzione di ricerca

Start in crates/socket-patch-cli/src/commands/vendor.rs at run_revert, compare its forward warning path with go_consumer_sync::audit_warnings, then trace the vendored branches in rollback.rs and remove.rs. Read the apply --check / vendor --check handling to see why a stale vendor/modules.txt is not detected once no replacement entry remains. Done means all three undo paths emit go_vendor_modules_txt_out_of_sync and a later check fails until go mod vendor/go work vendor is run; check open PR #1778 before duplicating work.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

agent:claimed agent:triaged bug bughunt pm:go priority:p2

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

Summary

Take a Go project with a committed vendor/ directory that was patched in vendored mode, with go mod vendor re-run as the forward warning asks. Undoing the patch with vendor --revert, rollback or remove <purl> drops the go.mod replace and exits 0 with status success. None of them warns go_vendor_modules_txt_out_of_sync, and vendor --check and apply --check both exit 0 afterwards. But vendor/modules.txt still records the removed replace, so the next default build fails:

go: inconsistent vendoring in …/c:
	example.com/[email protected]: is marked as replaced in vendor/modules.txt, but not replaced in go.mod

Agent mode handles the same situation correctly. After apply → go mod vendor → rollback, the CLI warns go_vendor_modules_txt_out_of_sync and apply --check exits 1 with "still records a socket-patch replacement … run go mod vendor". This is the #343 fix. Only the vendored undo paths miss it.

Impact

Repos that commit vendor/ are the main audience for vendored mode (air-gapped and frozen CI). There, every vendored undo leaves the default build broken, and nothing tells the user to run go mod vendor. This includes the cleanup a user does when moving away from vendored mode. It's a rewrite that makes the next frozen build fail, while the CLI reports success and its own audits pass.

Expected vs actual

docs/ecosystems.md, "Files go derives from go.mod": apply, vendor, rollback and scan --mode hosted warn with the command that does the regeneration, and apply --check / vendor --check report the disagreement as drift until it is run. The warning covers a vendor/modules.txt that "does not record a socket replace, or still records one that was removed".

  • Expected: vendor --revert, rollback and remove warn go_vendor_modules_txt_out_of_sync with go mod vendor (or go work vendor), as agent rollback does, and a later check fails until the regeneration is done.
  • Actual: no warning (rollback only reports reinstall_required), exit 0, and both checks exit 0.

Repro

This uses a hermetic HTTP GOPROXY and a local mock of the patch API. POST /v0/orgs/<org>/patches/package returns a granted tarball: an example.com/[email protected]/ module zip with a patched lib.go, plus sha512 integrity, in the vendor/golang.rs mount_go_granted shape. GET …/patches/view/<uuid> returns the record.

export GOFLAGS= GOENV=off GOTOOLCHAIN=local GOPROXY=http://127.0.0.1:$PORT/proxy GOSUMDB=sum.invalid.example
API="--api-url http://127.0.0.1:$PORT --org test-org --api-token fake"
# consumer: go 1.21, require example.com/upstream v1.0.0, go.sum has the upstream lines
go mod vendor && git add -A && git commit -qm vendored-dir
socket-patch get $UUID --mode vendored --yes $API   # exit 0, warns go_vendor_modules_txt_out_of_sync (correct)
go mod vendor && go run .                           # OUT: PATCHED
git add -A && git commit -qm patched

socket-patch vendor --revert --json      # exit 0, status success, warnings: []
socket-patch vendor --check              # exit 0
socket-patch apply --check --offline     # exit 0
go run .                                 # exit 1: inconsistent vendoring (above)
# Same result from `git checkout . && git clean -fd` and then
#   socket-patch rollback --offline --json            -> exit 0, warnings: [reinstall_required]
#   socket-patch remove pkg:golang/example.com/[email protected] --offline --json  -> exit 0, warnings: []

# Control, agent mode on the same project shape:
#   apply --offline; go mod vendor; rollback --offline --json -> warnings: [go_vendor_modules_txt_out_of_sync]
#   apply --check -> exit 1 "still records a socket-patch replacement ..."

The same happens in a go.work workspace after go work vendor, both with use . at the root and in a non-root member (use ./a). The non-root member case overlaps #1766, which is agent mode. Its fix, #1767, only changes the audit in go_consumer_sync.rs, and vendored undo never calls that audit.

OS × version

OS go vendor --revert rollback remove
Linux 1.22.12 silent, build broken silent, build broken silent, build broken
Linux 1.24.7 (3 runs) silent, build broken silent, build broken silent, build broken
Linux 1.26.8 silent, build broken silent, build broken silent, build broken
macOS / Windows — untested (the code path is OS-independent)

It isn't a regression: the v5.0.1 release (npm @socketsecurity/[email protected]) behaves the same. Tested on main b787454.

Suspect code

  • crates/socket-patch-cli/src/commands/vendor.rs:4417 (run_revert) never calls go_consumer_sync::audit_warnings. The forward path does, at vendor.rs:4013-4026 (#343, #618).
  • crates/socket-patch-cli/src/commands/rollback.rs:3319-3329 only audits when a result is_local_go (the agent go-patches leg), so the vendored leg is skipped.
  • crates/socket-patch-cli/src/commands/remove.rs has no Go consumer audit at all.
  • apply --check / vendor --check never look at a stale modules.txt when no vendored or manifest entry is left, so they pass after the revert.

No probe runs: the sandbox is Linux-only, and the go/modules.txt logic involved is OS-independent.

Lingua principale
Rust
Stelle
8
Fork
2
Merge medio
19h 24m
PR unite (30g)
669

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di SocketDev/socket-patch

Tutte le issue di SocketDev/socket-patch

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.