Open repi opened 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.
Would it be possible to add support for automatically running
cargo audit
(or checking directly against RUSTSEC like we do incargo-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.