Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run cargo audit on upgraded crate before building it #190

Open
repi opened this issue Sep 9, 2022 · 1 comment
Open

Run cargo audit on upgraded crate before building it #190

repi opened this issue Sep 9, 2022 · 1 comment

Comments

@repi
Copy link

repi commented Sep 9, 2022

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: rust-lang/cargo#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
Copy link
Owner

nabijaczleweli commented Sep 9, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants