GeezerVison

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 (Warn during pnpm scans when non-registry copies cannot be patched #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 (Warn during pnpm scans when non-registry copies cannot be patched #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:

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