Withhold Cargo pins a member's other source or other patch bypasses

crates/socket-patch-cli/CLI_CONTRACT.md

@@ -547,7 +547,7 @@ Recognition rules that hold for every ecosystem:
 * **Patch hosts.** A hosted reference counts only on `https://patch.socket.dev` or the `--patch-server-url` / `SOCKET_PATCH_SERVER_URL` origin, with no userinfo. The uuid is the URL's LAST canonical-uuid path segment, because grant tokens may themselves be uuid-shaped. The Go module prefix is fixed. `socket-patch-<uuid>` registry / repository / source names count only through a pin. For a URL on any other host, see **Patch hosts** above.
 * **Pins, not definitions.** A registry, index or source *definition* alone (cargo `[registries]`, nuget `<add>`, pom `<repository>`, uv index tables, `.npmrc`) never makes a reference, because it survives a reverted pin. Sections the package manager ignores are not read: npm's v2 `dependencies` mirror, a `.cargo/config.toml` shadowed by `.cargo/config`. A Socket pin inside a maven `<profile>` is diagnosed, never a reference.
 * **Contested locks.** When one lock wires a package to a patch and another lock resolves the same `name@version` from a non-Socket source, the build's bytes depend on which package manager runs. The reference is then dropped with a `patched_ref_unattributable` diagnostic naming both files. This applies across npm / pnpm / yarn / bun and across uv / pylock / poetry / pdm / Pipfile.lock / requirements. PEP 723 script locks neither contest nor are contested. The root `requirements.txt` and its in-root `-r` includes count as one lock here: pip reads them as one requirement set, where a direct reference wins over a compatible `==` pin of the same version in another file of the set (#1086). A PyPI version matches under PEP 440 equality, so a requirements line pinned in any spelling that can only install the wired release (`==1.2.3.0`, `==v1.2.3`, `===1.2.3`) contests it like `==1.2.3` does; a range or wildcard (`~=1.2.3`, `==1.2.*`) does not (#1602). A **bundled** npm copy (`inBundle: true`, or v1 `bundled: true`, beneath a dependency that bundles it; the root project's own bundles install from the lock, #1618) of the same `name@version` contests the reference too, in the same lock, in the other npm lock of a shrinkwrap/package-lock pair, or in any other lock. npm unpacks it from the parent package's tarball, so no rewire reaches it and it stays unpatched. Bun and vlt unpack bundled copies the same way (#469, #471). pnpm unpacks bundled copies too, but its lock cannot tie one to a reference (see **Unattested references** below). For Bun, that is a `bun.lock` entry whose meta is `{ "bundled": true }`, or a `bun.lockb` record that a dependency edge with the `bundled` behavior bit reaches, including one Bun shares with a regular install. Such an entry is never a reference, and it contests the reference the same way. For vlt, the lock records no node for a bundled copy, so the copy is found in the installed store: a real package directory inside a store package's own `node_modules`. yarn classic's `yarn.lock` records nothing about bundled copies either (#758), so for a lock with a Socket wiring they are found in the installed `node_modules`: each package a parent's `bundleDependencies` / `bundledDependencies` names inside the parent's own `node_modules`, the dependencies of those beside them, and everything nested under them. Such a copy contests the reference in `yarn.lock` (the diagnostic names the parent's lock entry and the copy's directory); a lock-only `vex` with no `node_modules` can't see it. Hosted and vendored scans skip these copies with `redirect_bun_bundled_instance_skipped` / `redirect_vlt_bundled_instance_skipped` / `vendor_bundled_instance_skipped`, and a yarn classic hosted scan names one with `redirect_copy_unpatched`. When a bundled copy is the only instance, vendoring refuses with `vendor_lock_entry_not_rewritable`. A reference withheld only because such an unreachable copy installs beside it (a bundled npm / Bun / vlt copy, an npm copy beneath a `hasShrinkwrap` package (#753) or one npm installs from a git / url / `file:` spec, or a yarn classic git or `file:` directory block of the same `name@version`) is still the rewriter's own wiring of exactly one package version: it is never attested, but `rollback`, `remove`, `list` and the hosted → vendored takeover treat it as an ordinary hosted pin and restore its upstream registry entry (#828), rather than refusing it with `hosted_wiring_contested`. Another entry of the **same** npm, Bun or yarn lock that resolves the wired `name@version` from a non-Socket source (for example a workspace member added after the rewire, then `npm install` / `bun install` / `yarn install`; for yarn berry, a registry locator such as `left-pad@npm:1.3.0` beside the hosted `…::__archiveUrl=` one) contests the reference too (#588). The package manager installs both entries, and that copy stays unpatched. Re-running `scan` / `vendor` rewires every copy.
-* **Unattested references.** Some evidence shows a build may run a copy no wiring reaches, but cannot be tied to the reference's exact `name@version` or cannot say the build runs it. The reference then stays a reference: `list`, `rollback` and `remove` find it, and the ledgers' liveness gates (`vendor --check`, `scan`) keep treating the wiring as live, because re-running `scan` / `vendor` could never clear the evidence. Only `vex` omits it, as a run warning and as the `failed[].reason`. Five cases besides Gradle's (`vex_gradle_lock_above_base`): **pnpm bundled copies** (`vex_pnpm_bundled_copy`): a `packages:` entry's `bundledDependencies:` names the copies pnpm unpacks from that package's own tarball, but pnpm never locks them, so the bundled version is not in the lock. A pnpm reference whose package name a `bundledDependencies` list in the same lock names is omitted whatever its version (a missed attestation when the bundled copy is another version, never a false one), and `bundledDependencies: true` (or a value that cannot be read) omits every reference of that lock. It reaches no other lock. **deno.lock** (`vex_deno_lock_copy`): `deno install` installs a `package.json` project's npm dependencies from `deno.lock` and never reads `package-lock.json` / `pnpm-lock.yaml` / `yarn.lock`, so an npm-family reference whose `name@version` the `deno.lock` npm section also locks is omitted (#406). Whether Deno or another package manager populates `node_modules` (`nodeModulesDir: "manual"` allows either) is not in the files, so this holds whatever `nodeModulesDir` says. **Maven reactor roots** (`vex_maven_reactor_root`): a hosted pin in a root `pom.xml` that declares `<modules>` / `<subprojects>`, or whose subprojects Maven 4 discovers (see the hosted Maven rewriter), is omitted, because a module's own literal `<version>` overrides a root pin and module poms are not read (#261); hosted scan refuses such roots (`redirect_maven_multimodule_unsupported`), so this only covers pins an older release wrote. **Maven classifier copies** (`vex_maven_classifier_unpatched`): a `<classifier>` dependency of a hosted-pinned GA is its own coordinate; the classifier-less pin does not retarget it and the grant serves only the main jar, so Maven fetches it from the next repository. When a live, non-profile classifier copy other than `sources` / `javadoc` (`tests`, a native or JDK-specific build) resolves any version other than the suffixed pin — its own literal `<version>`, a `<dependencyManagement>` entry with the same classifier, or no version in the root pom — the pin is omitted. `sources` / `javadoc` copies never run on a classpath and do not withhold the statement; hosted scan only warns about them (`redirect_maven_classifier_unsupported`) and skips the dep when an executable copy names the patched release. **Unpinned Cargo declarations** (`vex_cargo_unpinned_declaration`): cargo resolves each source on its own, so when one declaration of a crate pins it to `socket-patch-<uuid>` but another — the root `Cargo.toml`'s or a workspace member's, read as hosted scan reads them — names no Socket registry (crates.io, another registry, a path or git) with a version requirement the locked patched version satisfies, that declaration builds a separate, unpatched copy, possibly of the very version the pin covers. The `Cargo.lock` reference is omitted, naming the unpinned declaration's manifest, and the warning also names a same-version lock entry from another source when the lock already holds one. Hosted scan pins every declaration, so this is a partial revert or a hand edit; re-running `scan` pins a crates.io declaration again. A declaration whose requirement excludes the patched version (cargo resolves it to another version) does not withhold the statement.
+* **Unattested references.** Some evidence shows a build may run a copy no wiring reaches, but cannot be tied to the reference's exact `name@version` or cannot say the build runs it. The reference then stays a reference: `list`, `rollback` and `remove` find it, and the ledgers' liveness gates (`vendor --check`, `scan`) keep treating the wiring as live, because re-running `scan` / `vendor` could never clear the evidence. Only `vex` omits it, as a run warning and as the `failed[].reason`. Six cases besides Gradle's (`vex_gradle_lock_above_base`): **pnpm bundled copies** (`vex_pnpm_bundled_copy`): a `packages:` entry's `bundledDependencies:` names the copies pnpm unpacks from that package's own tarball, but pnpm never locks them, so the bundled version is not in the lock. A pnpm reference whose package name a `bundledDependencies` list in the same lock names is omitted whatever its version (a missed attestation when the bundled copy is another version, never a false one), and `bundledDependencies: true` (or a value that cannot be read) omits every reference of that lock. It reaches no other lock. **deno.lock** (`vex_deno_lock_copy`): `deno install` installs a `package.json` project's npm dependencies from `deno.lock` and never reads `package-lock.json` / `pnpm-lock.yaml` / `yarn.lock`, so an npm-family reference whose `name@version` the `deno.lock` npm section also locks is omitted (#406). Whether Deno or another package manager populates `node_modules` (`nodeModulesDir: "manual"` allows either) is not in the files, so this holds whatever `nodeModulesDir` says. **Maven reactor roots** (`vex_maven_reactor_root`): a hosted pin in a root `pom.xml` that declares `<modules>` / `<subprojects>`, or whose subprojects Maven 4 discovers (see the hosted Maven rewriter), is omitted, because a module's own literal `<version>` overrides a root pin and module poms are not read (#261); hosted scan refuses such roots (`redirect_maven_multimodule_unsupported`), so this only covers pins an older release wrote. **Maven classifier copies** (`vex_maven_classifier_unpatched`): a `<classifier>` dependency of a hosted-pinned GA is its own coordinate; the classifier-less pin does not retarget it and the grant serves only the main jar, so Maven fetches it from the next repository. When a live, non-profile classifier copy other than `sources` / `javadoc` (`tests`, a native or JDK-specific build) resolves any version other than the suffixed pin — its own literal `<version>`, a `<dependencyManagement>` entry with the same classifier, or no version in the root pom — the pin is omitted. `sources` / `javadoc` copies never run on a classpath and do not withhold the statement; hosted scan only warns about them (`redirect_maven_classifier_unsupported`) and skips the dep when an executable copy names the patched release. **Unpinned Cargo declarations** (`vex_cargo_unpinned_declaration`): cargo resolves each source on its own, so when one declaration of a crate pins it to `socket-patch-<uuid>` but another — the root `Cargo.toml`'s or a workspace member's, read as hosted scan reads them — names no Socket registry (crates.io, another registry, a path or git) with a version requirement the locked patched version satisfies, that declaration builds a separate, unpatched copy, possibly of the very version the pin covers. The `Cargo.lock` reference is omitted, naming the unpinned declaration's manifest, and the warning also names a same-version lock entry from another source when the lock already holds one. Hosted scan pins every declaration, so this is a partial revert or a hand edit; re-running `scan` pins a crates.io declaration again. A declaration whose requirement excludes the patched version (cargo resolves it to another version) does not withhold the statement. **Vendored Cargo copies a `[patch]` does not reach** (`vex_cargo_patch_bypassed`): a `[patch.<source>]` entry replaces the crate only in declarations from `<source>`, and `vendor` writes `[patch.crates-io]`. So a vendored reference is omitted when a declaration of the crate (the root `Cargo.toml`'s or a workspace member's) names another registry or a git repository with a version requirement the patched version satisfies, and no `[patch]` table for that source points at the same copy; cargo builds that declaration's own, unpatched copy. It is also omitted when `Cargo.lock` locks the crate at exactly the patched version from any source (a registry, crates.io included, or git) beside the vendored copy; the warning names that lock entry. A path declaration (the user's own fork) does not withhold the statement. Re-running `vendor` does not change this; declare the crate from crates.io there, or roll the patch back. When the root pins a crate to one Socket patch and a workspace member pins it to another that `Cargo.lock` does not resolve, both wirings are reported, so `vex` omits the package as `wiring_conflict`.
 * **Shrinkwrap without a twin (#899).** npm >= 12 never reads `npm-shrinkwrap.json`: on a project whose only npm lock is the shrinkwrap it resolves the tree from the registry and writes a fresh `package-lock.json`, so a Socket reference there reaches npm <= 11 only. The reference is still discovered, so `list`, `rollback` and `remove` manage it, but `vex` omits the patch (`vex_npm_shrinkwrap_only`, as a run warning and as the `failed[].reason`). A `package-lock.json` beside it (wired the same way) makes it attestable again. Hosted and vendored runs still rewire the shrinkwrap and warn `redirect_npm_shrinkwrap_only` / `vendor_npm_shrinkwrap_only`.
 * **Lockless pins.** With no lock to name a version, a `Cargo.toml` pin (every declaration on `socket-patch-<uuid>`, that registry defined on the patch host for the same uuid) or an exclusive nuget exact-id mapping is never a reference on its own, so v5.0 does not attest it (nor does `list` show it, or `rollback` / `remove` restore it — restore those files from version control). Only a pre-v5 redirect-ledger record naming a version the pin admits keeps it live. The same holds for a gem wired only in the `Gemfile` (the pre-bundler-2.6 mixed state, lock not converged).
 
@@ -2679,6 +2679,7 @@ match it, withholds the statement:
 | `vex_maven_reactor_root` | run warning and `failed[].reason` | A hosted Maven pin sits in a root `pom.xml` that declares `<modules>` / `<subprojects>` (a profile's included), where a module's own literal `<version>` overrides it; only the root pom is read, so no statement (#261). `list`, `rollback` and `remove` still find the pin. |
 | `vex_maven_classifier_unpatched` | run warning and `failed[].reason` | A hosted Maven pin's GA also has a live executable `<classifier>` copy (not `sources` / `javadoc`) at a version other than the pin, which the classifier-less pin does not retarget and the grant does not serve; no statement while it does. `list`, `rollback` and `remove` still find the pin. |
 | `vex_cargo_unpinned_declaration` | run warning and `failed[].reason` | A hosted Cargo pin is wired, but another declaration of the crate (the root's or a workspace member's) names no Socket registry and accepts the patched version, so cargo builds a separate unpatched copy for it; no statement while it does. `list`, `rollback` and `remove` still find the pin. |
+| `vex_cargo_patch_bypassed` | run warning and `failed[].reason` | A vendored Cargo copy is wired, but a declaration of the crate from another registry or git accepts the patched version, or `Cargo.lock` locks that version from a registry or git, and the copy's `[patch]` entry does not redirect it; no statement while it does. `list`, `rollback` and `remove` still find the wiring. |
 | `vex_gradle_derived_cache_unchecked` | run warning | The derived-cache walk was cut short (a very large transforms cache); the statement is still emitted, the copies the walk did reach were checked. |
 
 A vendored Gradle entry attests only while its wiring is live (apply line, index rows,

crates/socket-patch-cli/src/commands/vex_sources.rs

@@ -236,6 +236,10 @@ const NOTE_MAVEN_CLASSIFIER_UNPATCHED: &str = "vex_maven_classifier_unpatched";
 /// the crate that names no Socket registry, which cargo resolves as a
 /// separate, unpatched package (`vex::Unattested`).
 const NOTE_CARGO_UNPINNED_DECLARATION: &str = "vex_cargo_unpinned_declaration";
+/// Omission tag and note: a vendored Cargo copy beside a copy of the crate
+/// from a source its `[patch]` entry does not redirect (another registry,
+/// git), which cargo builds unpatched (`vex::Unattested`).
+const NOTE_CARGO_PATCH_BYPASSED: &str = "vex_cargo_patch_bypassed";
 
 /// The omission tag of an [`Unattested`](socket_patch_core::vex::Unattested)
 /// ref, and the remedy its note ends with.
@@ -278,6 +282,12 @@ fn unattested_note(kind: UnattestedKind) -> (&'static str, &'static str) {
              `socket-patch scan` to pin a crates.io declaration too; one from another \
              registry, a path or git cannot be pinned, so roll the patch back)",
         ),
+        UnattestedKind::CargoPatchBypassed => (
+            NOTE_CARGO_PATCH_BYPASSED,
+            "not attested while that copy builds; the vendored wiring itself is intact, so \
+             re-running `vendor` does not change this (declare the crate from crates.io \
+             there, or roll the patch back)",
+        ),
     }
 }
 
@@ -1818,6 +1828,55 @@ mod tests {
         );
     }
 
+    /// A vendored Cargo copy beside a copy of the crate its `[patch]`
+    /// entry does not redirect is omitted as `vex_cargo_patch_bypassed`,
+    /// the note naming that copy and the remedy.
+    #[tokio::test]
+    async fn a_vendored_cargo_copy_beside_a_bypassing_source_is_gated() {
+        const PURL: &str = "pkg:cargo/serde@1.0.1";
+        let tmp = tempfile::tempdir().unwrap();
+        let mut manifest = PatchManifest::new();
+        manifest.patches.insert(PURL.into(), record(U1));
+        let vref = vendor_ref(&format!(".socket/vendor/cargo/{U1}/serde-1.0.1")).unwrap();
+        let mut found = discovery(vec![PatchedRef::vendored(
+            PURL.into(),
+            &vref,
+            "Cargo.toml",
+            None,
+        )]);
+        found.unattested.push(socket_patch_core::vex::Unattested {
+            purl: PURL.into(),
+            uuid: U1.into(),
+            file: "crates/a/Cargo.toml".into(),
+            detail: "crates/a/Cargo.toml declares serde \"1\" from registry `my-corp`".into(),
+            kind: UnattestedKind::CargoPatchBypassed,
+        });
+        let gated = plan(
+            &common(tmp.path()),
+            Sources {
+                manifest,
+                vendor: VendorState::new(),
+                redirect: None,
+                discovery: found,
+            },
+            &[],
+            &RunApiClient::new(),
+        )
+        .await;
+        assert!(gated.view.patches.is_empty() && gated.hosted.is_empty());
+        assert_eq!(gated.gated, vec![failed(PURL, NOTE_CARGO_PATCH_BYPASSED)]);
+        assert!(
+            gated
+                .notes
+                .iter()
+                .any(|n| n.code == NOTE_CARGO_PATCH_BYPASSED
+                    && n.detail.contains("from registry `my-corp`")
+                    && n.detail.contains("re-running `vendor`")),
+            "{:?}",
+            gated.notes
+        );
+    }
+
     /// Ledger-only records with no wiring anywhere are gated, except the
     /// manifest-owned one, which falls back to agent-mode verification; an
     /// in-run confirmed purl is live by construction.