GeezerVison

Stacked on #940. This branch now contains #940's current head (acbac79a), merged in at b83da9c4, because the yarn same-lock rule used here comes from #940's Discovery::unpatched_copy. Until #940 merges, this diff also shows #940's commits. Merge #940 first. This PR's own commits are 176327d1, a0f253a5, 5e5d88d7, 7fb32e8f and, after the merge, 9ac96fc6, 98d9b0b2, e9a33b85.

Problem

Audit workstream vex-false-attest (B05, B04): standalone vex attested not_affected from a lock's hosted pin while the copy the build runs stayed unpatched.

• B05 / In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519, yarn Plug'n'Play. The package_not_found → lockfile-basis excuse (commands/vex.rs) assumed that when the crawler finds no copy, nothing is installed. Under yarn PnP the crawler can't look: packages are zips that .pnp.cjs / .pnp.js resolves. A hosted lock pulled over an existing PnP install was attested while the loader still resolved the registry copy (yarn 1.12–1.22, berry 4.0–4.18; repros on In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519).
• B04, pnpm bundled copies. pnpm unpacks bundledDependencies from the parent's tarball and never locks them. The npm, bun and vlt extractors already handle a ref beside a bundled copy. The pnpm extractor had no bundled handling.
• Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406, Deno. deno install installs a package.json project's npm deps from deno.lock and never reads package-lock.json. Because the deno extractor was empty, a package-lock.json pin was attested.
• Found in review: yarn berry registry locator in the same lock. A berry registry locator (left-pad@npm:1.3.0) next to the hosted …::__archiveUrl= locator of the same version was only cross-lock evidence, so the same lock never contested the hosted ref. yarn installs both copies. The PnP loader check matches the patch anywhere in the loader text, so a loader that names both locators would also have attested.

Change

• PnP (In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519). crawlers::pkg_managers::YarnPnpLoader (new; reuses detect_npm_pkg_manager) reads .pnp.cjs, .pnp.js, .pnp.loader.mjs and .pnp.data.json. resolves_patch(uuid, urls) checks whether the loader names the patch:
  • yarn berry: the hosted url's uuid. Checked against real yarn 4.12.0.
  • yarn 1: the #sha1 of the resolved url in the cache folder name. Checked against real yarn 1.22.22.
  • vex.rs treats a PnP project whose loader doesn't resolve the patch as "the crawler didn't look", next to the pnpm out-of-project store (Hosted pnpm vex attests not_affected over an unpatched install when pnpm's modulesDir is set (pnpm 10.12+), because the missed install is treated as "nothing installed" #696). The purl stays omitted (package_not_found).
• Unattested refs (pnpm bundled copies, deno.lock). These two cases now keep the ref and only block the attestation. They are recorded as a Discovery::unwired_copy (UnwiredCopy). Once every extractor has run, the orchestrator turns each one into an Unattested mark on every ref it may sit next to. This is the mechanism Gradle already used.
  • The ref stays a ref, so list, rollback, remove and the ledgers' liveness gates (vendor --check, scan) still see the wiring as live.
  • Only vex omits it, with vex_pnpm_bundled_copy or vex_deno_lock_copy and a remedy specific to each case. Unattested gains an UnattestedKind so the Gradle code (vex_gradle_lock_above_base) is no longer used for every case.
  • pnpm: formats::pnpm::grammar::entry_bundled reads bundledDependencies:: the block list and true that real pnpm 11.27 writes, plus a flow list. Any other value fails closed to "all". A ref whose name a list in the same lock names is marked whatever its version, because the lock doesn't record the bundled copy's version. true marks every ref of that lock. The mark never reaches another lock.
  • Deno: the deno.lock npm section (lockfile v2/v3/v4/v5 layouts, with Deno's _peer suffix stripped) marks a ref of the same name@version in any lock. deno.lock still never yields a ref.
• yarn berry same-lock rule. Berry plain-registry and custom-registry entries now go through Discovery::unpatched_copy, as yarn classic registry blocks already do (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). This does drop the ref. That is correct here: re-running scan / vendor rewires every copy, just like the npm / Bun / classic same-lock rule.
• Docs: CLI_CONTRACT.md gets a new "Unattested references" bullet, the deno row, two new rows in the vex code table, and the yarn same-lock sentence. docs/testing/yarn-berry-compatibility.md gets the PnP contract.

Liveness impact, stated explicitly: an earlier revision of this PR fed the pnpm bundled and Deno evidence into unpatched_copy / resolved_elsewhere. Those drop the ref, so any pnpm lock with one bundledDependencies: true package failed vendor --check for every vendored npm entry in it, and a Deno project failed for every same-version entry. Both failures came with a "re-run socket-patch vendor" or "delete the stale lock" remedy that could never clear them. With this revision, neither case affects vendor --check or scan liveness. Only the new berry same-lock contest affects liveness, and re-running scan / vendor does clear it.

Duplicate copies deleted: none. This is a behavior fix. The pnpm bundled and Deno cases reuse the existing Unattested mechanism (previously Gradle-only), and the matching runs once in the orchestrator (unattest_unwired_copies), not in a per-extractor loop over out.refs. The yarn fix reuses #940's unpatched_copy. One pre-existing duplication remains: npm (push_uncontested) and vlt (contest_bundled_copies) each still emit their own bundled-copy diagnostic instead of using unpatched_copy (see Deferred).

Fixes #519
Refs #406: standalone vex no longer attests. The in-run scan --mode hosted --vex path (assume_applied) and a scan warning about deno.lock are still open.

Review response

Testing

Each new regression test fails on the code before its fix and passes now:

Commands run (macOS, CARGO_INCREMENTAL=0, through /private/tmp/claude-501/heavy-job.sh, -j4):

• cargo test -p socket-patch-core --lib -- vex:: crawlers:: formats:: patch::redirect vendor::: 4379 passed. The vex-discover-golden/redirect-npm.json golden was regenerated; the only change is new unpatched_copies rows for 9 berry fixtures (no ref changed).
• cargo test -p socket-patch-cli --lib --test e2e_vex_lockfile --test e2e_vex_vendor --test e2e_vex --test e2e_vex_redirect --test e2e_embedded_vex --test covgap_commands_vex --test e2e_safety_yarn_pnp --test vex_terminal_output --test e2e_vex_build --test contract_gradle_codes: all passed (867 lib, 324 lockfile, 29 vendor, 19, 31, 15, 12, 36, 12, 1; vex_build cells ignored locally).
• cargo test -p socket-patch-cli for every suite that touches yarn.lock (in_process_vendor, in_process_redirect, in_process_rollback_hosted, in_process_get_modes, covgap_commands_{vendor,rollback,scan_mod}, e2e_{redirect,vendor}_yarn_berry_build, e2e_yarn4_workspaces_build, e2e_yarn_legacy_cachekey_refusal_build, hosted_memory_{parity,engine}, global_scope_project_state, cli_parse_list, e2e_{hosted,vendored}_production, mode_migration_npm): all passed except mode_migration_npm::berry_vendored_then_hosted_takeover_leaves_pure_hosted. That test fails identically with this PR's yarn change reverted (a hosted resolutions entry is left in package.json with the local real yarn), so it is not caused by this PR; CI will show whether it is local-only.
• cargo clippy -p socket-patch-core -p socket-patch-cli --tests -- -D warnings: no findings in any touched file. The local run fails only on lints already in files this PR doesn't touch (python_crawler.rs unused unix_default on macOS, jvm_jar.rs, maven_repo.rs, nuget_feed.rs, test prebuilt_common, …).
• rustfmt was run only on the touched files.

Deferred

• Maven integrity_required = false (part of B05): unchanged on purpose. Requiring Trusted Checksums would stop lock-only attestation for ordinary hosted Maven projects. This is maintainer decision E46, still open.
• npm / vlt bundled-copy duplication: push_uncontested (npm) and contest_bundled_copies (vlt) still emit their own bundled-copy diagnostics instead of using Discovery::unpatched_copy. This predates the PR and is left for a follow-up consolidation.
• Narrowing pnpm bundledDependencies: true to the names in the parent's snapshots dependencies. It only costs attestations now, not liveness.
• yarn 1 PnP where the lock's resolved has no #sha1 fragment: the purl stays omitted (a missed attestation, never a false one).
• Yarn classic VEX attests not_affected while a bundled copy of the patched package@version stays unpatched (yarn.lock has no inBundle, so the #325 fix can't see it) #758 (yarn classic bundled copy): yarn.lock doesn't record bundled copies, so lockfile-only discovery can't see them.
• Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406: the in-run scan --vex path and a hosted-scan warning for deno.lock.
• pm:pnpm / npm / bun-claimed issues (Warn during pnpm scans when non-registry copies cannot be patched #935, Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466, Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497, With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635, npm hosted and vendored modes rewrite a lock entry nested under a dependency that ships npm-shrinkwrap.json (hasShrinkwrap), so npm 7–11 install it unpatched while vendored VEX attests not_affected #753, npm 12 never reads npm-shrinkwrap.json, so on a shrinkwrap-only project hosted and vendored scans rewrite a lock npm 12 ignores: scan succeeds with no warning, lockfile-only VEX attests not_affected, and npm install installs the unpatched package #899, …) are out of scope, owned by Fix 15 open pnpm issues across hosted, vendored and agent modes #1007 / Fix open npm issues #1008 / Fix open bun issues (#992, #861, #784, #764, #735, #635, #599, #578, #497, #443, #371) #1009 and Fix VEX attesting beside an unpatched same-lock copy (#935, #938, #939) #940.

🤖 Generated with Claude Code

Generated by Claude Code