cargo install should run cargo audit

[nathan-at-least]

Problem

I just ran cargo install rage, a new file encryption tool. What if there is a vulnerability disclosure present? I have no way of knowing. I cannot use cargo audit AFAIK to discover vulnerabilities unless I clone the upstream source crate and then run cargo audit there.

Proposed Solution

When a user runs cargo install foo, it should display cargo audit output for the package.

Notes

This isn't ideal, since cargo audit reports are primarily aimed towards developers rather than users, but it gives cautious users some basis to decide whether to rely on the installed package. If they're uncomfortable they can cargo uninstall.

[nathan-at-least]

I believe this feature request is distinct from #7678 which is about providing cargo audit out of the box for developers, whereas this ticket is a feature request for users who install packages.

[Eh2406]

cargo audit is a third party command. I.E. code we do not control nor have much say in. If it one day is included as a first party part of Cargo, the RFC describing how to include it will have to go over how it is integrated into Cargos API.

[alilleybrinker]

The distinction of something being intended for developers vs. intended for users also isn't trivial. npm has gotten a lot of flask for raising what are, from the perspective of users, irrelevant or unimportant vulnerabilities in their dependencies, leading either to resentment of the presentation of the information and/or ignoring it entirely. Over-signaling security information can drown out the important stuff and kill that information channel for future use.

Probably worthwhile to think about what a version of cargo audit that is focused on users, perhaps taking into consideration context-specific information to decide how and whether to report certain findings, would look like.

[nathan-at-least]

@alilleybrinker that's an excellent point. I filed a wishlist / exploratory ticket with rustsec that I believe may help address this issue: rustsec/rustsec#505

The idea is that if a (non-dev) user installs a package, foo, and the hypothetical new future cargo-audit which supports that wishlist feature still reports a vulnerability, this means the maintainers of package foo haven't taken the time to understand the vulnerability and provide guidance to their users. In that case, I would suggest that complaining loudly to the users is the right move. If the foo maintainers are aware of the underlying vulnerability disclosure and have at a minimum documented their awareness of it, then the tool would not display a warning. (Ideally the documentation would explain for non-dev users how the given vuln may affect the usage of foo.)

Perhaps I'm too optimistic, though. ;-)

[kornelski]

Warning about rustsec vulnerabilities doesn’t necessarily needs to be implemented by running check on the client side.

The crates.io registry could be tracking the rustsec status and send a warning down to cargo.

[alilleybrinker]

One thing that's developed more since this was initially filed is the concept of Vulnerability Exploitability eXchange (VEX) data, which is intended to be a machine-readable mechanism for software producers to communicate to their own users about whether vulnerabilities in a dependency impact users of software which incorporates that dependency. If something like the proposed feature here is pursued, I think integration of VEX (along with some easy way for Rust package maintainers to publish VEX disclosures to Crates.io) would help avoid the false positive flood issue I'd described previously.