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.
As an easy start, how about letting build scripts read /usr, read and write a temporary build directory, have some /tmp scratch space, and be allowed to write its final output artifact. No network and otherwise isolated from the rest of the system.
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.
Cargo is a cross-platform tool, so when it ships a sandboxing solution it will need to be a cross-platform solution, and because this is a security feature it needs to be bulletproof, so no half-measures like Docker. Something like a WASM runtime might fit the bill, though that will be much easier to get working for typical proc macros than for typical build scripts. If you only care about Unix, then you can do this yourself today by building code in your sandbox of choice.
> Cargo is a cross-platform tool, so when it ships a sandboxing solution it will need to be a cross-platform solution
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.
So let each build script define its own level of sandboxing and then users can determine whether they are okay with that level or not, e.g. `cargo build --sandbox-level=...`
Rust, like C, C++, and every other systems programming language, is all about giving users the power to make mistakes. The philosophical difference when it comes to Rust is simply that it tries to force the user to flip off the safety on the gun before letting you shoot yourself in the foot. A Cargo config option letting people opt-out of sandboxing would be fully in line with Rust's philosophy.
Having a dangerous flag as a backwards compatibility flag is okay. I don’t think making users decide between multiple levels of sandboxing is constructive, they will just be trained to ignore it.
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.
No, the flag would not exist simply for backwards compatibility, it would exist because build scripts are occasionally necessary and there are plenty of legitimate uses for them, even if they should be opt-in.
