Build script allowlist mode

[opeik]

Problem

Build scripts are pragmatic but increase the surface area for supply chain attacks since they can execute arbitrary code. Most crates (at least in my experience) don't include build scripts. I propose a Cargo feature that disables build scripts if you're paranoid or working with tighter security requirements.

Proposed Solution

A build script allowlist mode (configured via Cargo.toml and friends) that prevents build scripts from executing when enabled. If a crate contains a build script and this option is enabled, the build script isn't executed, and compilation fails. The user can then audit the listed crates containing build scripts. If all is well, the user adds the audited crates to an allowlist, allowing build script execution for the specified crates.

Notes

A build script allowlist mode would be supplemented, but not replaced, by the ongoing sandboxing efforts. I'd argue it's substantially easier to implement, too. It may also discourage unnecessarily using build scripts, which is a win.

Relevant discussion:

• #5720
  • Sandbox build.rs and proc macros
• Pre-RFC: Sandboxed, deterministic, reproducible, efficient Wasm compilation of proc macros

[epage]

This seems incomplete as this wouldn't cover proc macros.

I also wonder if its worth discussing all potential controls within #5720

[heisen-li]

I know the maintainers are wary of adding warnings and such, but perhaps a hint during cargo check or elsewhere could be [security tip] : a custom build script exists for the crate you are relying on.

As a temporary solution before implementing the RFC.

[epage]

Cargo's output is pretty noisy as is and providing an always-on unactionable message would likely not move forward.

With #12235, we'll be able to have more linting and would love to integrate a lot of cargo deny behavior. The main question is where these kind of lints should live, see https://blog.rust-lang.org/inside-rust/2024/03/26/this-development-cycle-in-cargo-1.78.html#linter-for-cargo