I’m disappointed crates.io doesn’t have a stricter bar for serving a crate that has newly acquired a proc macro or build.rs. That seems like a trivial mitigation.

Mitigation for what?

Compromising the code that is then most likely run in a test instead of compromising a build script is just a very slight inconvenience for the attacker.

I'm not particularly fond of arbitrary build scripts either, but restricting them will not help the supply chain issue in a significant way.

Also there are several ways to control build.rs execution in the Cargo ecosystem, for example with cargo-deny.

Defaults matter. It’s nice you can set this up using a plugin to protect yourself, but that doesn’t protect the ecosystem, most of which doesn’t use cargo deny.

I also disagree a build scripts is a mild convenience. A build script always runs for anyone it’s a dependency for with full access and context and often has access to secrets in CI. A compromised runtime has more limited access and requires actual invocation of code paths (if you’re lying as a dependency that’s never executed, no exploit).

Of course Rust should have language-level support for capabilities so that just invoking a function doesn’t grant it access to arbitrary disk access. But that’s a much more difficult change than tweaking the defaults for cargo.

As mentioned by others it’s just as easy for an attacker to modify a crate’s runtime code.

So? Runtime code requires actually executing the malicious code path which isn’t an immediate 100% hit rate for everyone that includes it in the dependency chain. For build.rs it’s a 100% compromise of everyone it’s in the dependency chain for. Additionally, at runtime you may not have access to secrets whereas at build time you most certainly do.

The malicious code could use life-before-main hacks to gain code execution if it's linked at all, even if uncalled. https://grack.com/blog/2026/06/11/life-before-main/

It doesn’t take away from the point that build time often has access to secrets the runtime does not.