Fix npm/Bun VEX attesting a patch a same-lock copy skips (#588) by mikolalysenko · Pull Request #589 · SocketDev/socket-patch

Mikola Lysenko (mikolalysenko) · 2026-10-02T18:23:23Z

LLM Description written by Claude Code:claude-opus-5-5

Fixes #588

Summary

A package-lock.json can wire one copy of name@version to the Socket artifact while a second entry for the same name@version in the same lock still resolves from the registry. That's the normal state after vendoring, adding a workspace member that needs the same version, and running npm install. npm ci then installs that copy unpatched, yet:

vendored vex (with or without --no-verify) and hosted vex --no-verify attested not_affected;
vendor --check passed with "committed artifact and wiring verified".

Now that copy contests the reference. vex omits the purl with a patched_ref_unattributable diagnostic that names the entry and says to re-run vendor / scan. vendor --check fails with vendor_check_failed, naming the unwired entry.

Root cause

VEX: vex/discover/npm.rs push_uncontested only let an unwired registry entry contest a ref when it was in the other npm lock (*j != i). Bundled copies (npm VEX attests not_affected while a bundled (inBundle) copy of the same package@version stays unpatched #325) and non-registry copies (npm hosted and vendored modes rewire git-sourced lock entries, so npm ci silently installs the unpatched git bytes while scan and VEX report success #326) were already contested inside the same lock; a registry copy was not. The Bun extractor (vex/discover/bun.rs) had the same gap. The issue reports that the Bun routine reproduced it with bun.lock.
vendor --check: run_check verified only the committed artifact for npm entries and never looked at the lock.

What changed

vendor/lock_inventory/npm.rs: new npm_lock_located_nodes, the shared lock walk with each entry's location (the packages key or the v1 chain). The bundled walk already produced locations.
vex/discover/npm.rs: unwired maps each purl to its first location. push_uncontested contests a ref when its own lock has an unwired entry for the same purl, before the existing cross-lock check.
vex/discover/bun.rs: classify returns the purl of a registry entry, and a new Unwired set contests same-lock refs after the bundled contest, for both bun.lock and bun.lockb.
vendor/npm_lock.rs check_wiring and vendor/npm_flavor.rs check_npm_wiring: for a package-lock ledger entry, every entry vendor would rewire (scan_lock_matches, the same set) in each present npm lock must resolve to file:<artifact>. commands/vendor.rs run_check calls it for npm entries. Other npm flavors are unchanged (Ok).
CLI_CONTRACT.md (contested locks, vendor --check) and CHANGELOG.md are updated.

No wrapper (npm/, pypi/, gem/) changes are needed: they only dispatch to the binary.

Test evidence

Issue facet	Regression test	On `main`	With fix
npm lock, hosted + vendored ref contested by a same-lock registry copy; a different version doesn't contest	`vex::discover::npm::tests::issue_588_unwired_registry_copy_in_the_same_lock_contests_the_ref`	FAILED (ref attested)	ok
Bun twin (`bun.lock`), hosted + vendored	`vex::discover::bun::tests::issue_588_registry_copy_in_the_same_lock_contests_the_ref`	FAILED (contest disabled)	ok
CLI `vex` (vendored, no `node_modules`) does not attest	`e2e_vex_vendor::vendored_npm_patch_with_an_unwired_registry_copy_in_the_same_lock`	FAILED: exit 0, `not_affected`	ok
CLI `vendor --check` fails naming `packages/b/node_modules/lodash`	same test, run with only the VEX commits applied	FAILED: exit 0, `vendor_check_ok`	ok

The red runs were made in a separate worktree on origin/main with only the new tests copied in. The vendor --check row was checked separately by applying only the VEX commits.

Commands run locally:

cargo clippy --workspace --all-features -- -D warnings: clean on the head. An intermediate commit carried an unused re-export, which is what CI's clippy flagged on 5ce219e / 8d1a570; it's removed in c7479de.
rustfmt --check: every hunk this PR adds is clean. main already has unformatted code elsewhere, and CI doesn't gate on fmt.
cargo test -p socket-patch-core --lib: 4833 passed, 4 failed. The 4 are the known root-sandbox permission tests (relax_loop_must_not_traverse_symlinked_root, an_unremovable_hidden_lock_keeps_every_store_entry, wire_write_failure_maps_error_and_leaves_lock_untouched, wire_failure_rolls_back_already_written_files).
cargo test -p socket-patch-cli --all-features on e2e_vex, e2e_vex_lockfile, e2e_vex_redirect, e2e_vex_vendor, covgap_commands_vex, in_process_vendor, in_process_vendor_bun_takeover, mode_migration_npm, mode_migration_bun, vendor_eject*: 532 passed, 0 failed.
covgap_commands_vendor: 41 passed, 3 failed. The 3 are *_state_write_failure_* tests, which can't fail as root in this sandbox.
e2e_vendor_npm_build and e2e_vendor_bun_build with --include-ignored: 17 + 14 passed.
A full cargo test --workspace doesn't fit in this sandbox's disk allowance, so CI runs the rest.

CI status (`a0a210c`: 453 passed, 6 skipped, 1 failed, 1 re-running)

native (ubuntu-latest, 1.4.2) (Bun): one cell failed after its 3 transport retries, with patches-api Connection reset by peer. It's being re-run once (19:28 UTC).
scan performance: red on main as well. Both yarn-berry scenarios are invalid on the base binary too, because of a stale benchmark expectation after Fix yarn berry hosted pin leaking npm auth (#404) #465. The fixture-only fix is Stream ZIP member hashes during vendored verification #587's 329b146. It isn't ported here (see the PR comment): either Stream ZIP member hashes during vendored verification #587 lands first, or a maintainer cherry-picks it.
Bugbot reviewed a0a210c with no findings.

Per-issue checklist

npm vendored vex and vendor --check pass while a second registry copy of the patched package@version in the same package-lock.json stays unwired and installs unpatched #588 vendored vex / vex --no-verify don't attest: npm discover test + CLI e2e_vex_vendor test
npm vendored vex and vendor --check pass while a second registry copy of the patched package@version in the same package-lock.json stays unwired and installs unpatched #588 hosted vex --no-verify doesn't attest: hosted case of the npm discover test (the same discovery path)
npm vendored vex and vendor --check pass while a second registry copy of the patched package@version in the same package-lock.json stays unwired and installs unpatched #588 vendor --check reports the unwired copy as drift: CLI e2e_vex_vendor test
npm vendored vex and vendor --check pass while a second registry copy of the patched package@version in the same package-lock.json stays unwired and installs unpatched #588 Bun variant mentioned in the report: Bun discover test

🤖 Generated with Claude Code

https://claude.ai/code/session_01FN6qdGNobQZG6C41AQMb5V

Note

Medium Risk
Changes VEX attestation and vendor audit logic for npm/Bun lock discovery; incorrect contest detection could wrongly suppress attestations or fail checks, but scope is limited to duplicate same-version lock entries.

Overview
Fixes #588: when one lock entry wires name@version to Socket but another entry in the same npm or Bun lock still resolves that version from the registry (typical after vendoring, then adding a workspace member and running install), the package manager installs an unpatched copy alongside the patched one.

vex now treats that registry entry as a same-lock contest (like bundled copies already did). Discovery drops the patch ref with patched_ref_unattributable, names the unwired lock path, and tells users to re-run vendor / scan. npm uses npm_lock_located_nodes and maps unwired purls to locations; Bun adds an Unwired pass after classification for bun.lock / bun.lockb.

vendor --check for package-lock entries runs new wiring audit check_wiring: every rewritable packages instance must point at file:<vendored artifact>; drift fails with vendor_check_failed and names the offending entries.

CHANGELOG and CLI_CONTRACT document contested-lock and --check behavior. Regression tests cover npm/Bun discovery and CLI vex + vendor --check.

^{Reviewed by Cursor Bugbot for commit edc7c8b. Configure here.}

Generated by Claude Code

Assisted-by: Claude Code:claude-opus-5-5

A package-lock.json can wire one copy of name@version to the Socket artifact while another entry for the same name@version (a workspace member added after vendoring, then npm install) still resolves from the registry. npm ci installs that copy unpatched, but vex attested the patch as not_affected because only the sibling npm lock could contest a ref. An unwired entry in the ref's own lock now contests it too, with a diagnostic naming the entry and asking to re-run vendor / scan. Refs #588 Assisted-by: Claude Code:claude-opus-5-5

The bun.lock / bun.lockb twin of the npm fix: a second entry resolving a wired name@version from the registry installs unpatched beside the rewired one, so it now contests the ref instead of letting vex attest it as not_affected. Refs #588 Assisted-by: Claude Code:claude-opus-5-5

vendor --check only verified the committed artifact for npm entries, so it passed while package-lock.json still had a second entry for the patched name@version resolving from the registry. That copy installs unpatched and a reinstall cannot fix it. The check now re-scans every present npm lock for the entries vendor would rewire and fails with vendor_check_failed when one of them does not resolve to the vendored artifact, naming the entry. Refs #588 Assisted-by: Claude Code:claude-opus-5-5

Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) · 2026-10-02T18:49:51Z

[agent] CI: native (ubuntu-latest, 1.4.2) (Bun) failed on a0a210c. 51 of 52 cells passed. The only failing cell is 1.4.2 hoisted hosted, which ran out of its 3 transport retries.

I don't think this PR caused it:

Attempt 1 failed with Network error … patches-api.socket.dev/patch/batch: Connection reset by peer. Dozens of other cells in the same job hit the same resets and passed on retry.
The failing step moved on every attempt: cliSuccess, then vexApplyEmbedded, then repeatClean. Attempt 3 got past the vex steps, which are the only Bun code this PR changes (the same-lock contest in vex/discover/bun.rs), so the hosted ref was still attested there.

No fix is needed in this PR. I'll re-run the failed job once when the workflow finishes; the re-run API returns 403 "already running" until then. If it fails again, I'll treat it as real.

Generated by Claude Code

Mikola Lysenko (mikolalysenko) · 2026-10-02T18:57:31Z

BugBot review

Generated by Claude Code

Mikola Lysenko (mikolalysenko) · 2026-10-02T18:59:48Z

[agent] CI: scan performance failed on a0a210c. Every scenario's timing is unchanged. The job fails only because both yarn-berry scenarios are invalid on the base binary as well as the head: redirect.rewrittenFiles: got ["package.json", "yarn.lock"], want ["yarn.lock"].

This isn't caused by this PR, which doesn't touch yarn berry or the benchmark harness. The benchmark fixture (crates/socket-patch-bench/src/fixtures/npm.rs, build_yarn_berry) still expects only yarn.lock, but since #465 hosted Berry redirects also pin package.json. So the check is red against main itself.

A fixture-only fix already exists in #587 (329b146, "test: align Berry benchmarks with descriptor resolutions"), and scan performance passes on that commit. I haven't ported it into this PR: my session's safety policy blocks running another branch's code here. A maintainer can either let #587 land first and merge main in, or cherry-pick 329b146 onto this branch.

Generated by Claude Code

cursor

Stale Bugbot comment from a previous run.

…ck-unwired-copy

Mikola Lysenko (mikolalysenko) · 2026-10-02T20:20:38Z

bugbot run

Generated by Claude Code

cursor

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit edc7c8b. Configure here.}

Mikola Lysenko (mikolalysenko) · 2026-10-02T20:50:57Z

[burn-down agent] Labeled Ready for review at edc7c8b8ef2bea094f04c88928c342ee133e6639.

Sync: merged main @ 045d7ec. This brought in Stream ZIP member hashes during vendored verification #587 (b8bf049), which fixes the scan performance failure noted earlier; that check is green on this head. The merge was clean, with overlap only in CHANGELOG.md and CLI_CONTRACT.md. The local socket-patch-core npm/bun/lock_inventory lib tests pass: 879 passed, 0 failed.
CI: 455/461 check runs green on this head (6 skipped by path/matrix filters), 0 failing. e2e (ubuntu-latest, e2e_redirect_maven_build, 3.9.16) first failed during a Maven Central outage: plugin artifacts such as maven-reporting-impl and asm:9.5 "could not be found", the same outage seen on Resolve vlt registry bases through one shared function (#562) #574. It passed on its single re-run. The Bun native (ubuntu-latest, 1.4.2) cell is green on this head.
Bugbot: reviewed edc7c8b and found no issues. No unresolved review threads.
What to look at: how npm/Bun VEX and vendor --check now let an unwired registry copy in the same lock compete with the wired ref for one name@version (npm vendored vex and vendor --check pass while a second registry copy of the patched package@version in the same package-lock.json stays unwired and installs unpatched #588). In particular, check that VEX no longer attests a patch that a same-lock copy skips.

Generated by Claude Code

Mikola Lysenko (mikolalysenko) · 2026-10-02T21:02:23Z

Reviewed edc7c8b8ef2bea094f04c88928c342ee133e6639. Ready to merge as-is; I found no actionable correctness or security issues.

The same-lock contest preserves UUID recognition, preventing an old ledger from reviving the dropped reference. I also verified the mixed sibling-lock case: when one npm lock is clean and the other contains both patched and registry copies, the full discovery pass drops every reference. The new npm wiring audit checks both locks and matches aliases by their real package identity.

Local validation passed: 41 npm discovery tests, 25 Bun discovery tests, the new CLI VEX/vendor-check regression, and 4 additional reviewer probes covering sibling locks, legacy nesting versus v2 mirrors, scoped aliases/prereleases, and both-lock audits (71 unique tests).

Exact-head CI is terminal: 455 checks passed, 7 skipped; all 13 workflows completed (12 successful, 1 skipped). Bugbot found no new issues on this head, there are no unresolved review threads, and the merge with current main 045d7ec7 is clean.

Start fix for #588

2fb1aff

Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) mentioned this pull request Oct 2, 2026

npm vendored vex and vendor --check pass while a second registry copy of the patched package@version in the same package-lock.json stays unwired and installs unpatched #588

Open

Claude (claude) added 5 commits October 2, 2026 18:31

Format the #588 changes

2ed972e

Assisted-by: Claude Code:claude-opus-5-5

Document same-lock npm copies contesting VEX

a0a210c

Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) changed the title ~~Fix npm VEX attesting a patch a same-lock copy skips (#588)~~ Fix npm/Bun VEX attesting a patch a same-lock copy skips (#588) Oct 2, 2026

Mikola Lysenko (mikolalysenko) marked this pull request as ready for review October 2, 2026 18:57

cursor Bot reviewed Oct 2, 2026

View reviewed changes

Mikola Lysenko (mikolalysenko) mentioned this pull request Oct 2, 2026

Fix hosted scan from a workspace member pinning nothing or the wrong files (#590, #417) #598

Open

Merge remote-tracking branch 'origin/main' into agent/fix-npm-same-lo…

edc7c8b

…ck-unwired-copy

cursor Bot reviewed Oct 2, 2026

View reviewed changes

Mikola Lysenko (mikolalysenko) added the Ready for review Agent-verified: mergeable, CI green, Bugbot clean — awaiting human review label Oct 2, 2026

Navigation Menu

Fix npm/Bun VEX attesting a patch a same-lock copy skips (#588) - #589

Fix npm/Bun VEX attesting a patch a same-lock copy skips (#588)#589
Mikola Lysenko (mikolalysenko) wants to merge 7 commits into
mainfrom
agent/fix-npm-same-lock-unwired-copy

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026 •

edited

Loading

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Uh oh!

cursor Bot left a comment •

edited

Loading

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Uh oh!

cursor Bot left a comment

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

LLM Description written by Claude Code:claude-opus-5-5

Summary

Root cause

What changed

Test evidence

CI status (a0a210c: 453 passed, 6 skipped, 1 failed, 1 re-running)

Per-issue checklist

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Uh oh!

cursor Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026 •

edited

Loading

CI status (`a0a210c`: 453 passed, 6 skipped, 1 failed, 1 re-running)

cursor Bot left a comment •

edited

Loading