Sandboxing for build scripts can't work properly. If you sandbox too much, some necessary stuff can't be done. If you sandbox too little, it has no practical value.
I would argue that, if a build script doesn’t work in the setting, then it doesn’t deserve to be installable by a default cargo command.
This seems like an excuse, not an actual objection.
Linux can do seccomp or Landlock or gVisor or a combination. Seccomp and gVisor need no privileges. Windows has its internal weird mechanisms. Mac has sandbox-exec.
Cargo could easily pick an appropriate sandbox for each major platform and ship it by default.
> If you only care about Unix, then you can do this yourself today by building code in your sandbox of choice.
This is ridiculous. The sandbox should not have network access, but cargo needs network access to download the package in the first place.
If you have a serious proposal, then I encourage someone to seriously propose it. Cargo is an understaffed open source project that, like the rest of the Rust project, relies largely on volunteers. However, gesturing to unspecified internal weird mechanisms does not strike me as a serious proposal worthy of consideration by anyone, so I'd suggest working on that first.
> The sandbox should not have network access, but cargo needs network access to download the package in the first place.
Naturally. Use `cargo fetch` to download a package locally without invoking any build step: https://doc.rust-lang.org/cargo/commands/cargo-fetch.html
This is the kind of decision users likely don’t understand without looking at the source code of a crate and it’s bad UX to push it to be their responsibility.