Separating fetching from building for better security

Sure, I fully agree with the different parts of your assessment. I still hope that these wrappers provide a meaningful contribution to defense in depth.

By the way, many programs do not need network for tests. When launched with skn-cargo test, tests will not have network, unless the user opts-in explicitly with skn-cargo +N test.

My observation from working on this project is that cargo tooling is surprisingly opaque. The involved mechanisms seem to be hidden within the individual cargo subcommands. This leads to the situation where for example rust-analyzer needs more permissions than necessary (see e.g. RA does not work at all when offline · Issue #12499 · rust-lang/rust-analyzer · GitHub, or Running rust-analyzer without write access to disk · Issue #22118 · rust-lang/rust-analyzer · GitHub). This is not universal across LSP servers.

Perhaps, in an ideal world, Cargo could expose a stable API with a more comprehensive internal model of operations and required effects. The Cargo subcommands would then be just one way to use it, and tools such as rust-analyzer would not have to approximate this by shelling out to CLI Cargo.

The --fetch-only idea is just one possible step towards this general goal. It won’t magically make Cargo safe, but I believe that it would be a useful building block whenever sandboxing primitives are available.