Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#455 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
55/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
rust
Domaine
cli, tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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).
Langage dominant
Rust
Étoiles
8
Forks
0
Merge moyen
18 h 4 min
PR mergées (30 j)
70

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de SocketDev/socket-patch

Toutes les issues de SocketDev/socket-patch

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.