{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiej5bosh3rrbtvoucnvxnq2u4yu4dzwudnf3erh3hg2znsuprhpse",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mnz6ksbmppw2"
  },
  "path": "/t/separating-fetching-from-building-for-better-security/24390#post_1",
  "publishedAt": "2026-06-11T09:34:59.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "Like other language package managers",
    "There are efforts to address this problem",
    "particularly troublesome in terms of security",
    "The Rust Programming Language Forum – 11 Jun 26",
    "Sandboxed wrappers for Cargo and rust-analyzer on Linux"
  ],
  "textContent": "Cargo and rust-analyzer are great, but their convenience comes with some security challenges:\n\n  * Like other language package managers, Cargo is subject to supply-chain attacks;\n  * Rust might be particularly exposed in that merely building a project can execute arbitrary code from any dependency via build scripts and proc macros. There are efforts to address this problem, but as far as I can see, a solution is not imminent;\n  * rust-analyzer, while extremely useful and convenient, is arguably particularly troublesome in terms of security.\n\n\n\nI’ve been working on what I hope is a pragmatic remedy to these problems:\n\nThe Rust Programming Language Forum – 11 Jun 26\n\n### Sandboxed wrappers for Cargo and rust-analyzer on Linux\n\nannouncements\n\nI continued developing and using these wrappers. With the latest release (0.3.0) they are now drop-in replacements for real Cargo and rust-analyzer for most practical workflows. The additional value that the wrappers provide is maintaining two...\n\nWhile working on this, I realized that in addition to simply sandboxing Cargo, a meaningful security improvement can be obtained by separating fetching and building so that, for example, an invocation of `cargo build` is split into two phases:\n\n  * A first phase that roughly runs `cargo fetch` in a sandbox with network enabled.\n\n  * A second phase that runs `cargo build --locked` in a sandbox with network disabled.\n\n\n\n\nThe security gain from the above is that if a compromised dependency tried to exfiltrate user data over the network (even if a sandbox is used, sensitive project data might be available), it would have a much harder time doing so.\n\nThe hard problem is reproducing exactly the fetches that a particular Cargo/rust-analyzer invocation would perform, including features, targets, manifests, sysroot/library details, etc. The Cargo and rust-analyzer wrappers that I’ve been working on try their best, but with current Cargo this is necessarily a brittle affair. For example, truly replicating the fetches that some `cargo build` invocation would perform without running `cargo build` seems very difficult currently. The same problem exists for rust-analyzer’s fetches. My wrapper has to resort to running magic commands like\n\n\n    __CARGO_TEST_CHANNEL_OVERRIDE_DO_NOT_USE_THIS=nightly RUSTUP_TOOLCHAIN=$sysroot \\\n    cargo fetch --locked --manifest-path \"$library_manifest\"\n\n\nI wonder whether it would be a good idea to solve this brittleness by adding support for such sandboxing/separation to Cargo itself. Cargo could, for example, gain a `--fetch-only` option. Running `cargo --fetch-only build` would perform exactly the fetching that `cargo build` would otherwise perform, but stop before building. Rust-analyzer could gain a `--fetch-only` option as well.",
  "title": "Separating fetching from building for better security"
}