{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifj4lznmxdbpcq5qvw5ptxicfurdj25chikpbwlwqdhjiajqs3wxu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mo4oovfrpsr2"
  },
  "path": "/t/separating-fetching-from-building-for-better-security/24390#post_11",
  "publishedAt": "2026-06-12T20:44:58.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "similar wrapper script"
  ],
  "textContent": "Nemo157:\n\n> grothesque:\n>\n>> For example, truly replicating the fetches that some `cargo build` invocation would perform without running `cargo build` seems very difficult currently.\n>\n> Hmmm, this seems odd to me, I've been using a similar wrapper script for years doing a simple `cargo fetch` and not run into such issues.\n\nA simple `cargo fetch` often works, but I am not aware of a way to limit it to a particular set of Cargo features. In particular, I believe that there is no way to make it aware of the features needed for a particular `cargo build`. So it tends to fetch too much, which may or may not be a problem.\n\nBut `cargo fetch` can also fail to fetch enough for a particular `cargo build`. For example, suppose a crate has a direct dependency named `foo`, and `foo` has\n\n\n    [features]\n    tls = [\"dep:rustls\"]\n\n    [dependencies]\n    rustls = { version = \"...\", optional = true }\n\n\nA user can run\n\n\n      cargo build --features foo/tls\n\n\nwhich activates a feature of the direct dependency. But `cargo fetch` has no corresponding `--features` option, so a wrapper using `cargo fetch` alone cannot say “fetch exactly as that build would fetch”. If `rustls` is not already cached, the later `--frozen` build can fail.\n\nEven if one disregards such cases and if one does not worry about fetching more than necessary, making a wrapper cover most of Cargo’s command line interface (e.g. `+nightly`, `--config`, `-C`, etc.) is quite complicated.\n\nIn the two-phase fetch-then-build-workflow, `--frozen` is already close to the _second_ phase: run the requested command without allowing network access or lockfile changes. The missing _first_ phase is a way to ask Cargo to perform exactly the fetching that the command would need, then stop.\n\nIn this way `--fetch-only` would be a natural addition to the existing `--locked`, `--offline`, and `--frozen` options of Cargo. It would make it easy for wrappers like yours or mine to separate fetching from building cleanly and robustly.",
  "title": "Separating fetching from building for better security"
}