Separating fetching from building for better security

[ryanavella]

@epage

Cargo does not load config files from dependencies.

To clarify, if I have a dependency which checks their configs into source control and includes them in the published crate, cargo won't load them? Even if .cargo/config.toml includes a [patch] section, or something similar?

Regardless, it would be nice to know which cargo commands can execute arbitrary code vs. which commands can't, as it isn't obvious to me at first blush.

[epage]

@ryanavella

To clarify, if I have a dependency which checks their configs into source control and includes them in the published crate, cargo won't load them? Even if .cargo/config.toml includes a [patch] section, or something similar?

Correct. Config is for environmental / transient settings. It is dependent on the environment it is run from independent of the project. The one exception is cargo install which only loads user-wide config and not directory-config.

e.g. `cargo install` ignores `.cargo/config.toml`, making packages publishable-but-unbuildable, allthewhile they work when built normally · Issue #14001 · rust-lang/cargo · GitHub

@ryanavella

Regardless, it would be nice to know which cargo commands can execute arbitrary code vs. which commands can't, as it isn't obvious to me at first blush.

Most commands are likely to invoke rustc at some point (e.g. cargo metadata fails if rustc not in the path · Issue #8219 · rust-lang/cargo · GitHub ) and the rustc binary can be controlled by config.

So there are two parts to this

• Untrusted repos (affect nearly all commands) would be helped by more control over config loading ( Cargo config search meta issue. · Issue #9769 · rust-lang/cargo · GitHub ) or even a trust-based system (#t-cargo > build script and proc macro allow list @ )
• Untrusted dependencies (affect only build-related commands) would be helped by a variety of strategies dealing with build scripts and proc-macros.