nabijaczleweli / cargo-update

A cargo subcommand for checking and applying updates to installed executables
MIT License
1.22k stars 42 forks source link

Run `cargo audit` on upgraded crate before building it #190

Open repi opened 2 years ago

repi commented 2 years ago

Would it be possible to add support for automatically running cargo audit (or checking directly against RUSTSEC like we do in cargo-deny) to verify that the new version doesn't have outstanding security advisories on it (directly or transitively)? Possibly with command-line or config options of what category advisories to warn or fail on.

This would be a good automatic security layer for users in the case of eventual (reported) security exploits in dependencies and be a to fail upgrading to that version. Similar to not upgrading to crates that use yanked version but much broader and security-focused.

Related cargo issue: https://github.com/rust-lang/cargo/issues/10016. but think it can be even more important (and easier) to support this in cargo-update here as it is common to do large batch upgrades of locally installed tools, and as it is very easy to upgrade them with this, one likely runs the upgrades more often.

nabijaczleweli commented 2 years ago

Unlike #191 or #192, I don't think this is possible in trunk.

I would much rather not have a laundry list of configurations and tooling to keep the interface updated for (barring cargo, heh); even the cargo-binstall integration is made with a heavy heart, especially since the interface is so ass, but the speed-ups are undeniable.

That said, any checking could, I think, be delegated to a filter, executed with argv[1] = package name, argv[2] = new version, argv[3] = old version, &c. – in the simplest case you described the filter could literally be

#!/bin/sh
exec cargo audit "$1" # ...; I failed to find an actionable manual in the cargo-audit repository,
                      #      so no clue what the invocation is, but I assume you feed it $2 here too

if the filter exits nonzero, the build is skipped, essentially as-if cargo install failed.

Thoughts?

Like #191 and #192, any solution is made much better with a file of global defaults. Or just invoking ~/.cargo/cargo-update-install-hook by default.