Fix VEX attesting beside an unpatched same-lock copy (#935, #938, #939)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #938
Refs #935
Refs #939

Summary

A lockfile-only vex attested a package as not_affected even though the same lock also installed an unpatched copy of that exact name@version:

• pnpm (pnpm VEX attests not_affected while a file: directory or file: tarball copy of the patched package@version in the same pnpm-lock.yaml installs unpatched, and hosted/vendored scans give no warning for that copy #935): a file: directory or file: tarball copy beside the Socket-wired registry entry.
• yarn classic (Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938): a registry block of the same version beside the Socket block, e.g. after yarn add -W left-pad --exact. yarn 1 installs one copy per name@version, from whichever block it resolves first.
• yarn berry (Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939): a file: / url copy locked under another dependency name (lp2@file:…). The resolutions pin never reaches it.

Root cause (shared)

VEX discovery had no shared same-lock rule. contest_across_locks (vex/discover/mod.rs) skips evidence from the ref's own lock (e.file != r.source_file), so each extractor wrote its own same-lock check. Only npm (push_uncontested unwired) and yarn classic git copies had one.

Change

• Discovery::unpatched_copy + contest_within_locks (vex/discover/mod.rs): one same-lock rule every extractor shares. An extractor records a copy, and every ref of the same name@version in that lock is dropped with patched_ref_unattributable. The diagnostic names the copy's lock entry and how it installs. The copy also counts as resolved_elsewhere evidence for the cross-lock contest. It runs before contest_across_locks.
• yarn classic: a non-Socket tarball block becomes a copy (Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938). The git-copy post-filter (Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363) now goes through the shared rule instead of its own loop.
• pnpm: file: directory / tarball entries (v9 name@file: keys and legacy file: keys) become copies (pnpm VEX attests not_affected while a file: directory or file: tarball copy of the patched package@version in the same pnpm-lock.yaml installs unpatched, and hosted/vendored scans give no warning for that copy #935). Name and version come from the key and the name: / version: fields, falling back to the directory's or tarball's package.json. A directory holding another version is not a copy.
• yarn berry: a non-Socket file: / url locator becomes a copy of the package it really holds (Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939). The name is read from the file: tarball's package.json, the file: directory's package.json (path resolved against the locator= workspace), or the registry tarball url path (…/<name>/-/<name>-<version>.tgz). A copy whose package can't be read is left alone.
• The vendored post-install vex gaps in Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938 / Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939 close through the same path. Discovery still recognizes the uuid but emits no ref for it, so the vendor ledger's claim is dead (rule 11) and is not attested.
• Ports Route Gradle digests through utils::digest #878 (7eda8d8, cherry-pick of 659ac2c). main fails utils::digest::tests::production_digests_go_through_the_helpers (the coverage / test-release jobs), and Route Gradle digests through utils::digest #878 is the open fix. This becomes a no-op once Route Gradle digests through utils::digest #878 lands.

Why #935 and #939 are Refs, not Fixes

Both issues also ask the hosted / vendored scans to warn about the unreached copy. That is a separate gap in four rewriters (pnpm and berry, hosted and vendored), not this discovery boundary. This PR fixes the false VEX attestation for both. The scan warnings are left as a follow-up on those issues.

Test evidence

Regression tests, red with contest_within_locks disabled and green with it:

Issue	Test
#935	vex::discover::npm::tests::issue_935_same_lock_file_copy_contests_the_pnpm_ref: v9 dir, v9 tgz, legacy dir, plus controls (wiring alone; dir of another version)
#938	vex::discover::yarn::tests::issue_938_classic_registry_block_of_the_same_version_contests_the_ref: plus control (registry block of another version)
#939	vex::discover::yarn::tests::issue_939_berry_other_name_copy_contests_the_ref: file: tgz, file: dir, registry url, plus controls (wiring alone; file: copies holding another package)

The existing classic_git_pattern_copies_are_never_attested also went red with the shared pass disabled, which confirms git copies now go through it.

Local runs:

• cargo test -p socket-patch-core --all-features --lib: 5248 passed. 4 permission-based tests fail only because this sandbox runs as root (copy_tree symlinked root, vlt_heal unremovable lock, poetry / requirements write failure). They pass in CI on main's head. The 5th failure was the digest guard, fixed by the Route Gradle digests through utils::digest #878 port.
• cargo test -p socket-patch-cli --all-features --lib --test e2e_vex_lockfile --test e2e_vex_redirect --test e2e_vex_vendor --test e2e_vex --test covgap_commands_vex: all green (847 + 12 + 19 + 311 + 31 + 28).
• cargo clippy --workspace --all-features -- -D warnings: clean.
• VEX discovery golden (redirect-npm.json): regenerated. The only change is an additive unpatched_copies section on yarn classic fixtures. No ref or diagnostic changed.
• cargo fmt: touched files are formatted. main itself isn't cargo fmt --check clean (about 120 files), and CI doesn't run fmt.
• Scan bench: the first push regressed yarn-classic/hosted / rescan by 16–18% because of a quadratic per-insert dedup. 980b7b6 removes it. A local socket-patch-bench compare --filter yarn-classic against main then shows +1.4% [-10.4, +8.1] and -3.0% [-8.1, +3.3], both ≈.

The npm / PyPI / gem wrappers don't need changes: this is Rust-only discovery logic.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RpNijzXr9S3AZY6xHUDwVH

---

Note

Medium Risk
Changes VEX discovery and attestation eligibility for npm-family locks when duplicate same-version install paths exist; behavior is fail-closed (drops refs, emits diagnostics) but affects security-relevant VEX output.

Overview
Stops false VEX not_affected claims when a lockfile both wires a package to a Socket patch and still installs an unpatched copy of the same name@version in that same lock—something cross-lock contest_across_locks never saw because it ignores evidence from the ref’s own file.

Discovery now has a shared unpatched_copy / contest_within_locks path: extractors record competing lock entries (with key + how they install), those copies also count as resolved_elsewhere, and matching refs are dropped with patched_ref_unattributable diagnostics that name the copy. The pass runs after all extractors and before cross-lock contesting.

pnpm (#935): file: directory and tarball entries (v9 and legacy keys); package identity from lock fields or the copy’s package.json / tarball.

Yarn classic (#938): non-Socket registry tarball blocks beside a Socket block (replacing a yarn-only post-filter); git and file: directory copies go through the same API.

Yarn berry (#939): file: / URL locators keyed under another dependency name; real package name from tarball, directory manifest, or registry URL path.

Golden discovery output gains an unpatched_copies section; regression tests cover the three issues plus controls (wrong version, different package, wiring alone).

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

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] native (windows-latest, 1.2.0) (Bun patch compatibility, run 37476785866) failed on one cell: 1.2.0 workspace vendored → refusalCodesExact. The other 48 cells passed. I think this is the patch API, not this PR, but I haven't confirmed it yet:

• the cell took ~15 s against ~1 s for its neighbours, and finished in the same second another cell got API request failed with status 504. That cell passed on the script's own retry.
• this PR only changes the npm / pnpm / yarn VEX discovery readers. The Bun reader (vex/discover/bun.rs) and the Bun vendored backend are untouched.
• the same workspace shape passed in hosted mode in this job, on every other Bun version on Windows, and on macOS.

The run is still in progress, so GitHub won't re-run the failed job yet (403 "already running"). I'll re-run it once when the run finishes. If it fails again, I'll pull captures/1.2.0-workspace-vendored/result.json from the job's results artifact and treat it as a real failure.

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Ready for review at 980b7b6.

• CI: 517/517 latest check runs green or skipped. The one red job, native (windows-latest, 1.2.0) in Bun patch compatibility, failed at the install step. It passed on a rerun of the same commit. The PR doesn't touch Bun code.
• Bugbot: reviewed 980b7b6 with no findings, and no review threads are unresolved.
• Mergeability: 0 commits behind main, no conflicts. It's waiting only on a required human review.
• For reviewers: the shared same-lock rule in vex/discover/mod.rs and how it's used in npm.rs and yarn.rs, plus the updated redirect-npm.json golden.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

bugbot run

[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 acbac79. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[agent] Merged at acbac79 (merge commit c5be5d1). Wrap-up:

• Conflicts: none. I merged main into the branch after Fix main CI red on stale digest pending-list entries #1016 landed (869c81f). A maintainer then merged main again (acbac79). The PR diff stayed limited to vex/discover/{mod,npm,yarn}.rs, the golden harness and redirect-npm.json.
• Local checks: clippy on socket-patch-core with -D warnings was clean. All 5594 socket-patch-core lib tests passed on acbac79, including the digest guard.
• CI on acbac79: the CI, Gradle, PDM, Pipenv, Go, Composer, sbt, npm and pnpm workflows passed. One red job: vlt / native (ubuntu-latest, 1.0.10), cell hosted-two-versions. Its capture shows redirect_vlt_artifact_unverifiable … fetch error error sending request against patch.socket.dev. That's a network flake, and this PR doesn't touch vlt or redirect code. The vendored and agent cells for the same fixture passed. The Bun and vlt runs were still queued when the PR merged.
• Bugbot: reviewed acbac79 and found no new issues.

Generated by Claude Code