{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihl4udmrooeubghyckb4auvg62qzwtcruasr7cbot5fwibmowetue",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mo4oon43qos2"
  },
  "path": "/t/separating-fetching-from-building-for-better-security/24390#post_13",
  "publishedAt": "2026-06-12T21:03:05.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "grothesque:\n\n> So it tends to fetch too much, which may or may not be a problem.\n\nHmm, I've never noticed `cargo build` not fetching the entire `Cargo.lock` before, but then I guess I never normally try to do a smaller build as the first step in a new project, I would start with a complete `cargo check` and so I wouldn't ever see it pulling extras.\n\ngrothesque:\n\n>\n>     cargo build --features foo/tls\n>\n\nAh, right, I _have_ run into such a situation before; I just disregard that as feeling like a bug in Cargo's CLI. It shouldn't be possible to activate a feature on a non-workspace crate during a particular build since the `Cargo.lock` doesn't contain the info necessary to do so. I assume it will just pull the latest of the unactivated optional dependencies each time?",
  "title": "Separating fetching from building for better security"
}