GeezerVison

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

Fixes #1630

Root cause

berry_copy_ref (crates/socket-patch-core/src/formats/yarn/copy.rs) read a yarn berry lock entry as a "copy under another dependency name" only when its reference was file:, portal:, link: or started with http. An exec: generator entry, and a git entry whose remote isn't http(s) (git+ssh://, ssh://, git://, git@host:), returned None, so:

• lockfile discovery (vex/discover/yarn.rs berry_block) skipped it silently, and the wired ref was attested not_affected;
• the hosted engine's redirect_copy_unpatched warning, which is fed by discovery, never named it;
• the vendored backend's other_name_copies never named it (vendor_copy_unpatched).

Fix

exec: and non-http git references are now read as copies whose package can't be read, like a non-registry url: possibly any package at the lock's version. That contests a wiring of the same version (patched_ref_unattributable), and both scans name the copy. exec: paths share the file:/portal:/link: selector and locator= parsing.

Tests (per issue)

• Yarn berry ignores an exec: copy of the patched package under another dependency name, so hosted and vendored scans succeed and VEX attests not_affected while that copy installs unpatched #1630, parsing: formats::yarn::copy::tests::issue_1630_exec_and_git_refs_are_unread_copies
• Yarn berry ignores an exec: copy of the patched package under another dependency name, so hosted and vendored scans succeed and VEX attests not_affected while that copy installs unpatched #1630, VEX discovery: vex::discover::yarn::tests::issue_1630_exec_and_git_copies_contest_a_vendored_ref (control: the same copy at 2.0.0 doesn't contest)
• Yarn berry ignores an exec: copy of the patched package under another dependency name, so hosted and vendored scans succeed and VEX attests not_affected while that copy installs unpatched #1630, vendored scan: vendor::yarn_berry_lock::tests::issue_939_other_name_copies_are_named gained exec: and git+ssh: cases
• Yarn berry ignores an exec: copy of the patched package under another dependency name, so hosted and vendored scans succeed and VEX attests not_affected while that copy installs unpatched #1630, hosted scan: hosted_memory_engine::issue_1630_berry_exec_and_git_copies_are_named (control at 2.0.0). It fails on main's core (redirect_copy_unpatched missing) and passes with the fix.

Commands run locally on d96f49a: cargo fmt --all -- --check ✅, cargo clippy --workspace --all-features -- -D warnings ✅, cargo test -p socket-patch-core --all-features --lib 6567 passed / 4 failed, cargo test -p socket-patch-cli --all-features --lib --test hosted_memory_engine ✅, all yarn CLI test binaries (non-ignored) ✅. The 4 core failures are chmod-based permission tests (copy_tree relax loop, vlt_heal unremovable lock, poetry/requirements wire-failure rollback) that can't fail a write when run as root, as this sandbox does. They don't touch yarn. A full cargo test --workspace ran out of the sandbox's disk, so CI covers the docker/e2e suites.

Code review (/code-review high) and what was not changed

• Fixed: duplicated exec: parsing, now shared with the file:/portal:/link: cascade; stale doc comments listing the copy kinds.
• Not changed, follow-up: yarn classic git dependencies under another name. classic_block records them as pkg:npm/<dep-name>@<version> rather than as an unidentified copy, and other_name_copies filters classic git out. Yarn berry ignores an exec: copy of the patched package under another dependency name, so hosted and vendored scans succeed and VEX attests not_affected while that copy installs unpatched #1630 is berry-only, so this PR doesn't widen to classic. The docs now say the git case is berry-only.
• Not changed: making berry_copy_ref fail-closed for unknown protocols (plugin resolvers). That is a policy change beyond Yarn berry ignores an exec: copy of the patched package under another dependency name, so hosted and vendored scans succeed and VEX attests not_affected while that copy installs unpatched #1630.
• Not changed: a git/exec: entry under the patched package's own name now contests in VEX but isn't named by vendored other_name_copies (same-name filter). That already happens for same-name file:/url entries on main, and VEX failing closed is the safe side.

https://claude.ai/code/session_01BgnkbqbEMV3JkJWHCPzG6E

Generated by Claude Code