search

mozilla / cargo-vet

supply-chain security for Rust
Apache License 2.0
621 stars 43 forks source link

`cargo vet check` only checks target-specific dependencies if `build.target` is used #579

Open Nemo157 opened 8 months ago

Nemo157 commented 8 months ago

When configuring build.target in ~/.cargo/config.toml or via CARGO_BUILD_TARGET cargo will default to implying --target $CARGO_BUILD_TARGET for all commands, including the cargo metadata call performed by cargo vet. This means that dependencies that are not active for the set target will not be checked.

> cargo vet regenerate exemptions
> cargo vet check --locked
Vetting Succeeded (83 fully audited, 2 partially audited, 26 exempted)
> env -u CARGO_BUILD_TARGET cargo vet check
Vetting Failed!

12 unvetted dependencies:
  android-tzdata:0.1.1 missing ["safe-to-deploy"]
  hermit-abi:0.3.2 missing ["safe-to-deploy"]
  iana-time-zone-haiku:0.1.2 missing ["safe-to-deploy"]
  js-sys:0.3.65 missing ["safe-to-deploy"]
  wasm-bindgen:0.2.88 missing ["safe-to-deploy"]
  wasm-bindgen-backend:0.2.88 missing ["safe-to-deploy"]
  wasm-bindgen-macro:0.2.88 missing ["safe-to-deploy"]
  wasm-bindgen-macro-support:0.2.88 missing ["safe-to-deploy"]
  wasm-bindgen-shared:0.2.88 missing ["safe-to-deploy"]
  winapi-i686-pc-windows-gnu:0.4.0 missing ["safe-to-deploy"]
  winapi-x86_64-pc-windows-gnu:0.4.0 missing ["safe-to-deploy"]
  windows-core:0.50.0 missing ["safe-to-deploy"]

This may be an upstream bug, I don't think build.target should imply --filter-platform on cargo metadata, but I'm not positive.

Nemo157 commented 8 months ago

Yes, upstream bug, but very long-standing so it would be nice if cargo-vet worked around it somehow

https://github.com/rust-lang/cargo/issues/8462

If it's configured through the environment like I do, it could just be unset on the sub-process call. If it's configured through the config file AFAIK there is no way to say "use the default all targets".