3 ms·

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 mitigatio

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.

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 ago
  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.
praseodym 2mo ago
As mentioned by others it’s just as easy for an attacker to modify a crate’s runtime code.
- vlovich123 2mo ago
  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.
  - dgrunwald 2mo ago
    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/ https://grack.com/blog/2026/06/11/life-before-main/
    - vlovich123 2mo ago
      It doesn’t take away from the point that build time often has access to secrets the runtime does not.

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.

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 ago
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.

praseodym 2mo ago

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

vlovich123 2mo ago
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.
- dgrunwald 2mo ago
  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/ https://grack.com/blog/2026/06/11/life-before-main/
  - vlovich123 2mo ago
    It doesn’t take away from the point that build time often has access to secrets the runtime does not.