3 ms·
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 fo
by weinzierl 2mo ago
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.
- vlovich123 2mo agoDefaults 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.