Feature request: Evaluate Cargo.toml

[joshlf]

While reading Cargo.lock is straightforward, one could easily have a Cargo.toml file that would allow semver resolution to pick a vulnerable version of a crate even if cargo didn't happen to pick that version in practice. It'd be cool if cargo audit could consume Cargo.toml and enumerate the set of every possibly valid choice of crate versions and emit a warning if any of them have known vulnerabilities. In response to this, the author could tighten the specification of which crate version is required.

[tarcieri]

The main way I think we'll end up interacting with Cargo.toml files is via cargo-edit (see #151)

Otherwise the scenarios where what you're describing can happen seem... pretty unusual. Here are a few I can think of:

• A new dependency is added which forces a SemVer-compatible downgrade to a vulnerable crate. But if they weren't SemVer compatible, it'd still pull in the vulnerable dependency anyway
• The user runs cargo update and is upgraded to a vulnerable version of a crate from an unaffected one
• The unaffected/patched version of a crate is yanked, the user runs cargo update, and is downgraded to a vulnerable non-yanked version

Have you actually encountered any of these (or something similar) in practice?

Otherwise I feel like trying to calculate all of the potential outcomes where you might end up with a vulnerable crate can't be done without duplicating Cargo's resolution logic or linking Cargo in as a library, the latter of which would significantly increase build times.

[joshlf]

I haven't encountered any of them, but they don't all seem so unlikely as to be not worth worrying about. I think that cargo updateing to a vulnerable version is probably the most likely.

I would say that this is probably worth leaving on the back burner until such a library exists (maybe the Cargo folks would be willing to factor it out into a crate?). Once that happens, it's probably a small enough amount of work that it's worth it. Before that, I agree that the work is probably not worth it. I also agree that linking Cargo as a library isn't worth it.

[tarcieri]

One way we could potentially consume Cargo.toml is via cargo metadata. The guppy library provides a parser for it which constructs dependency graphs using petgraph (the same library the cargo-lock crate uses for modeling the dependency graph today):

https://github.com/calibra/cargo-guppy