43 ms·

Unfortunately Cargo doesn’t have security controls in place to prevent these kinds of attacks. For example pnpm has controls to allowlist install scripts for de

Unfortunately Cargo doesn’t have security controls in place to prevent these kinds of attacks. For example pnpm has controls to allowlist install scripts for dependencies and will warn about new install scripts (without executing them). There is an open issue for this: https://github.com/rust-lang/cargo/issues/13681 https://github.com/rust-lang/cargo/issues/13681

weinzierl 1mo ago
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 share the dislike for arbitrary build scripts 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 as well, for example with cargo-deny.
- vlovich123 1mo ago
  Disallow lists are ineffective - better to disallow by default and require opt in. Also, crates.io can defer serving up newly uploaded scripts that have a new build.rs / proc-macro dependency and warn publicly that a version introduces it. Restricting build scripts 100% will help mitigate the impact, just not if you only deny it once. And they can develop other things like sandboxing for build scripts by default and escaping that to be the exception that has to be explicitly allowed.
- praseodym 1mo ago
  You’re right about attackers being able to change runtime code. pnpm does have some other features to prevent supply chain attacks, so there is still something to learn from other ecosystems. For example pnpm has a cooldown period for new dependencies and can prevent trust policy downgrades (eg new version published without build provenance where older versions did have it). See https://pnpm.io/supply-chain-security https://pnpm.io/supply-chain-security
  - faern 1mo ago
    > pnpm has a cooldown period for new dependencies Cargo has `min-publish-age` in nightly, and it's currently heading towards stabilization: https://github.com/rust-lang/cargo/pull/17335 https://github.com/rust-lang/cargo/pull/17335
- Aeolos 1mo ago
  The problem is that build scripts run automatically without user consent or intevention. `cargo add` is sufficient to compromise you, before you have a chance to even vet the code.
  - kibwen 1mo ago
    `cargo add` just modifies your Cargo.toml, it doesn't build anything.
    - xdavidliu 1mo ago
      https://shnatsel.medium.com/do-not-run-any-cargo-commands-on-untrusted-projects-4c31c89a78d6 https://shnatsel.medium.com/do-not-run-any-cargo-commands-on... > any command starting with cargo can run arbitrary code when operating on an untrusted repository, and should be treated the same as cargo run.
      - kibwen 1mo ago
        This comment is both true and entirely irrelevant. The context of this subthread is not running a Cargo command in a checkout of a malicious git repo, it's alleging that `cargo add foo` runs the build script of the crate `foo`, which is false.

weinzierl 1mo ago

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 share the dislike for arbitrary build scripts 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 as well, for example with cargo-deny.

vlovich123 1mo ago
Disallow lists are ineffective - better to disallow by default and require opt in. Also, crates.io can defer serving up newly uploaded scripts that have a new build.rs / proc-macro dependency and warn publicly that a version introduces it. Restricting build scripts 100% will help mitigate the impact, just not if you only deny it once. And they can develop other things like sandboxing for build scripts by default and escaping that to be the exception that has to be explicitly allowed.
praseodym 1mo ago
You’re right about attackers being able to change runtime code. pnpm does have some other features to prevent supply chain attacks, so there is still something to learn from other ecosystems. For example pnpm has a cooldown period for new dependencies and can prevent trust policy downgrades (eg new version published without build provenance where older versions did have it). See https://pnpm.io/supply-chain-security https://pnpm.io/supply-chain-security
- faern 1mo ago
  > pnpm has a cooldown period for new dependencies Cargo has `min-publish-age` in nightly, and it's currently heading towards stabilization: https://github.com/rust-lang/cargo/pull/17335 https://github.com/rust-lang/cargo/pull/17335
Aeolos 1mo ago
The problem is that build scripts run automatically without user consent or intevention. `cargo add` is sufficient to compromise you, before you have a chance to even vet the code.
- kibwen 1mo ago
  `cargo add` just modifies your Cargo.toml, it doesn't build anything.
  - xdavidliu 1mo ago
    https://shnatsel.medium.com/do-not-run-any-cargo-commands-on-untrusted-projects-4c31c89a78d6 https://shnatsel.medium.com/do-not-run-any-cargo-commands-on... > any command starting with cargo can run arbitrary code when operating on an untrusted repository, and should be treated the same as cargo run.
    - kibwen 1mo ago
      This comment is both true and entirely irrelevant. The context of this subthread is not running a Cargo command in a checkout of a malicious git repo, it's alleging that `cargo add foo` runs the build script of the crate `foo`, which is false.