Hosted cargo scan in a cargo vendor project reports success but breaks every fresh cargo build --frozen --offline, and VEX then omits the patch #455

[agent] Found by the scheduled Cargo bug-hunt routine (ledger #315).

Summary

Take a project that builds from a committed cargo vendor tree: vendor/ plus .cargo/config.toml with [source.crates-io] replace-with = "vendored-sources" / [source.vendored-sources] directory = "vendor". Run socket-patch scan --mode hosted on it. The redirect goes through as if the project fetched from crates.io:

• Cargo.toml gets cfg-if = { version = "1.0.4", registry = "socket-patch-<uuid>" },
• .cargo/config.toml gets [registries.socket-patch-<uuid>] index = "sparse+…" appended after the existing source replacement,
• Cargo.lock gets the per-patch sparse source and checksum,
• the scan exits 0 with redirected: 1 and warnings: [].

Nothing puts the patched crate into the directory source, and nothing replaces the new registry with it. vendor/cfg-if stays the stale, unpatched crates.io copy that nothing references any more. So the build this project is set up for, cargo build --frozen --offline from a fresh checkout, fails:

error: no matching package named `cfg-if` found
location searched: `socket-patch-c1f90104-5a0c-4e7a-9c0d-1a2b3c4d5e01` index
required by package `consumer v0.1.0 (…)`
note: offline mode (via `--frozen`) can sometimes cause surprising resolution failures

The only way to get it building again is to re-run cargo vendor with network access and hand-merge the [source."sparse+…"] replace-with = "vendored-sources" snippet it prints into .cargo/config.toml. socket-patch says nothing about this.

There's a second symptom. A fresh checkout that does build online (cargo fetch --locked, then build --locked --offline) links the patched crate from the per-patch registry. But vex on it prints omitting pkg:cargo/cfg-if@1.0.4 from VEX: the patched files still hold the original content (not_applied) and exits 1 with "No applied patches with vulnerability metadata to attest". The crawler hashes vendor/cfg-if, a copy the build no longer uses. That's the same hard-coded vendor/ lookup as #338, here as a false negative in hosted mode.

Impact

• cargo vendor is how offline, air-gapped and reproducible builds are usually done, and every CI build of such a repo uses --frozen / --offline. After a "successful" hosted scan, every fresh checkout of the project fails to build, and the failure points at a socket-patch registry rather than at what needs doing.
• When the project does build online, VEX won't attest a patch that's actually linked.
• Fails closed (nothing unpatched is attested), so this isn't a silent false fix. It's a broken build after a scan that reported success.

Repro

This uses the wiremock sparse-registry harness in crates/socket-patch-cli/tests/e2e_redirect_cargo_shapes.rs (local change, not committed). The baseline is the standard consumer_manifest("cfg-if = \"1.0.4\"\n") shape. After the baseline lock and build, and before the scan, the shape runs:

cargo vendor -q --locked vendor
mkdir -p .cargo && printf '[source.crates-io]\nreplace-with = "vendored-sources"\n\n[source.vendored-sources]\ndirectory = "vendor"\n' > .cargo/config.toml
cargo build -q --frozen --offline          # baseline: OK

Then the harness's usual chain runs, with one extra step after the scan: copy the committed files into a fresh dir with an empty CARGO_HOME, then build.

socket-patch scan --mode hosted --json --yes …   -> exit 0, redirected 1, warnings []
fresh: cargo build --frozen --offline            -> error: no matching package named `cfg-if` found (socket-patch-… index)
fresh: cargo fetch --locked && cargo build --locked --offline
                                                 -> OK, links cfg_if::socket_patched()
fresh: socket-patch vex --product pkg:cargo/consumer@0.1.0 …
                                                 -> "omitting pkg:cargo/cfg-if@1.0.4 … (not_applied)", exit 1
# manual recovery:
fresh: cargo vendor --locked vendor  (prints [source."sparse+http://…/index/"] replace-with = "vendored-sources")
       + merge that snippet into .cargo/config.toml
fresh: cargo build --frozen --offline            -> OK; vendor/cfg-if now patched; vex attests

It reproduced 3 of 3 times on Linux.

Expected vs actual

• Expected: docs/ecosystems.md (Cargo row) describes hosted mode as redirecting direct crates.io dependencies, with refusals for shapes where the redirect can't work (transitive dependents, lockless projects with other dependencies). It doesn't mention source replacement. A project whose crates.io source is replaced by a directory source can't build a per-patch registry crate offline. So hosted mode should either refuse loudly with nothing written (vendored mode already refuses a cargo vendor tree, with already_vendored_in_tree), or finish the job: vendor the patched .crate into the directory source and add the [source."sparse+…"] replace-with entry. At a minimum it should warn that cargo vendor must be re-run. Separately, vex should hash the copy cargo builds (see Agent-mode cargo apply patches the wrong copy when cargo vendor uses a custom directory (or apply runs from a workspace member), yet reports success and VEX attests not_affected #338).
• Actual: success, redirected: 1, no warning. Every --frozen/--offline build of a fresh checkout breaks, and VEX reports not_applied for a patch that is linked.

Matrix

Control: the same shape without vendor/ and the source replacement passes the whole chain (repo test cargo_hosted_legacy_config_is_restored_byte_for_byte and siblings, all green on 2463257).

Not bisected. Present on main 2463257 (#277).

Suspect code

• crates/socket-patch-core/src/patch/redirect/mod.rs:1062 (rewrite_cargo): plans the manifest, lock and [registries] edits without looking at [source.crates-io] replace-with / [source.*] directory in the project's .cargo/config*.
• crates/socket-patch-core/src/crawlers/cargo_crawler.rs:144 (get_crate_source_paths): returns <cwd>/vendor whenever it exists, so vex hashes the stale vendored copy instead of the per-patch registry copy cargo builds (same root cause as Agent-mode cargo apply patches the wrong copy when cargo vendor uses a custom directory (or apply runs from a workspace member), yet reports success and VEX attests not_affected #338, shape 3).