Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#455 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
cli, tooling

Rechercherichtung

Start with crates/socket-patch-core/src/patch/redirect/mod.rs:1062 (rewrite_cargo) and crates/socket-patch-core/src/crawlers/cargo_crawler.rs:144 (get_crate_source_paths). Run the wiremock scenario in crates/socket-patch-cli/tests/e2e_redirect_cargo_shapes.rs, then verify that hosted scans handle directory source replacement without breaking fresh offline builds and that VEX hashes the copy Cargo uses.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

agent:triaged bug bughunt pm:cargo priority:p2

[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/[email protected] 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/[email protected] …
                                                 -> "omitting pkg:cargo/[email protected] … (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 #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

OS cargo Lock fresh --frozen --offline build online fresh build vex
Linux 1.93.1 (repo toolchain) v4 fail (2/2) pass not_applied
Linux 1.97.0 (stable) v4 fail pass not_applied
macOS / Windows — — not probed. Cargo's source-replacement semantics and the rewriter are platform-independent

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 #338, shape 3).
Vorherrschende Sprache
Rust
Sterne
8
Forks
0
Ø Merge
18 Std. 4 Min.
Gemergte PRs (30 T.)
70

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus SocketDev/socket-patch

Alle Issues in SocketDev/socket-patch

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.