Dependencies for other (unused) platforms

help
1

When building an app for Linux (for example), I try to ignore/exclude dependencies that are specify to other targets (android, windows, wasm, ...).

The goals are multiples:

  • Reduce the risk of supply chain attacks
  • Reduce the number of review with cargo-vet
  • Reduce the diff when updating

For that, I use the following set-up:

In Cargo.coml :

[patch.crates-io]
android_system_properties = { path = "noop/android_system_properties" }

And in noop/android_system_properties I add the following file:

name = "android_system_properties"
version = "0.1.6"
edition = "2024"
publish = false

[lib]
path = "../lib.rs"

[features]
call = []

(../lib.rs is an existing empty file)

  • The version must be the same as in Cargo.lock
  • The [features] section is necessary to declare the features declared in the crate using it as a dependency

This works well with most crates (android_system_properties, libredox, wasm-bindgen, windows-sys, ...)

  • Any sub-dependency of those crates will be ignored (thus, not in Cargo.lock)
  • It prevent supply-chain attacks from those crates and all their dependencies
  • cargo vet will not ask for useless review

However, there is some drawbacks :

  • Some crates with a lot of features requires (a little) more work
  • When multiples versions are in the dependency tree, I need to declare all of them. For exemple: windows-sys-0-52 = { path = "noop/windows-sys-0.52", package = "windows-sys" }

And for some crates, I couldn't find a proper way to do it:

The crate cc declare find-msvc-tools but if that crate is an empty shell, the build will fail, because the code in cc use it even in for x86_64-unknown-linux-gnu.

Is there a more simple way to do it?

Ideally I would like to specify in a config file the build target(s), and that all dependencies that aren't for it will be ignored (no event be in Cargo.lock)

2

What about target-specific dependencies?

3

Well, they already are: socket2/Cargo.toml at v0.6.5 · rust-lang/socket2 · GitHub
(not find-msvc-tools but I'm thinking about opening a PR for that. Edit: Why find-msvc-tools is not behind a cfg(windows) guard? · Issue #1963 · rust-lang/cc-rs · GitHub)

But target-specific dependencies (and their dependent) always appear in Cargo.lock, and cargo vet still requires an audit for them and their dependent.

4

Why do you believe this will help against supply chain attacks?

5

For two reason:

  • If a platform-specific crate not under a config-guard ([target.'cfg(windows)'.dependencies]) or one of its dependency is infected, then this system help to prevent the installation of the malicious version.
  • With less crate to review with cargo vet, there is more time to review the crates really used and installed

It is not perfect, but I think it does improve the situation.