RustSec integration into crates.io UI

[Shnatsel]

Some crates on crates.io pull in vulnerable versions of transitive dependencies that do not have a semver-compatible upgrade path. An example of this is OpenSSL crate which is vulnerable to trivial MitM in versions prior to 0.9. There currently exists a crate with 8000+ downloads in the last 3 months that depends on a vulnerable version of OpenSSL, and this info is not exposed on crates.io in any way, so the crate might keep accumulating unsuspecting users.

We need to display vulnerabilities in transitive dependencies in crates.io UI so that people can fix or avoid poorly maintained dependencies.

Advisory database: https://github.com/RustSec/advisory-db
Tool for checking crates.io index against it: https://gitlab.com/zachreizner/crates-audit/ originally requested in #13

[tarcieri]

Potentially related issues:

rust-lang/cargo#2608
rust-lang/crates.io#145
rust-lang/crates.io#1153

[HadrienG2]

Besides the crates.io website, it would also be nice if the cargo CLI could (perhaps optionally) integrate some security warning features, such as what cargo-audit provides today.

As a crate developer, I usually only visit crates.io when looking for new dependencies, and most of the time all my crates.io interactions are through the cargo command-line tool. Therefore, if some important information is only displayed on the crates.io web frontend page associated with a crate that I depend on, I'm unlikely to see it. Whereas if it appears during my builds (or someone else's), I'm likely to learn about it more quickly.

[tarcieri]

Take a look at my proposal to add metadata to cargo yank including tying each security-related yank event to a RustSec advisory.

This seems like the path forward to me both for getting information on the crates.io web site as well as having some basic integration into cargo itself.

[Nemo157]

Another UI that I feel would make sense to integrate these messages is docs.rs, it seems much more likely for users of affected crates to be browsing the docs on docs.rs than visiting the crates.io page for it; so I think it would have the potential for a high impact.

Having extra data attached to the yank event would be a good start, but it doesn't really help cases where the crate has been abandoned and no owner is available to yank it. In those cases I think the websites do need to be directly sourcing data from the advisory db.