Making cargo-deny the official RustSec frontend?

[tarcieri]

Hello, I'm the primary maintainer of RustSec.

On a recent Reddit thread someone suggested deprecating cargo-audit in favor of cargo-deny. The reporting functionality in cargo-deny has definitely eclipsed what's in cargo-audit.

If this is something you're interested in, for me it's one fewer project to maintain.

My main concerns now are while from a reporting perspective cargo-deny is a superset, there are a few features I'm uncertain if cargo-deny supports at present:

• cargo audit fix-alike support (automatically update Cargo.toml to correct vulnerabilities)
• JSON reporting

Fortunately the core functionality of both of these features is already in the rustsec crate which cargo-deny already uses.

If this is something you're interested in pursuing, let me know.

[Jake-Shadle]

Yes, I think we would be fine with taking on that responsibility as most of the pieces are already there.

• If most of the fix functionality is in the rustsec crate already, it should hopefully be fairly easy to expose that as a new subcommand in cargo deny
• Structured/JSON reporting is tracked in Add structured output flag #137 and is something I started last week but just haven't had time to finish up yet, I haven't gotten to the advisories yet, but presumably I would just serialize the advisory information so shouldn't be a problem

I think I want to spend next week doing OS work, so I'll try and land the changes needed to close this issues, at least in terms of being able to be the official frontend.

[Jake-Shadle]

Ok, structured reporting has been done, will implement the fix subcommand now, then I was thinking could do a post users.rust-lang.org and maybe on Reddit as well for those who are not familar with cargo-deny already.

[tarcieri]

Sounds good!

If I understand correctly it looks like your JSON format is different from the one cargo-audit presently uses. If possible, it'd be nice to support the old format (as emitted by the rustsec crate) in addition to the new format for an initial cargo-audit -> cargo-deny migration, then phase out the old format at some point in the future (you could perhaps make the new format the default with an option to use the legacy format).

Another lingering item I'm curious if you're up for is call graph analysis to determine if a particular advisory impacts a given codebase. I'm happy to do the "heavy lifting" integration work on this in the rustsec crate as well (gated under a cargo feature).

[Jake-Shadle]

The top level json object for each advisory diagnostic is indeed not the same, but the fully serialized advisory object is available from /fields/advisory as I figured that would be sufficient for most use cases. If that was a bad assumption I can of course have a flag for the user to just output the direct advisory object instead.

So call graph analysis would indeed be interesting, but I unfortunately don't think it fits into the scope of cargo-deny, as we currently confine ourselves to the inputs (cargo graph, crates.io index, advisory database etc) without worrying about the actual outputs of the crate/workspace, and just today #243 was opened so that we can run cargo-deny in environments without rust/cargo installed at all.

We did open another project which is intended to be the flipside of cargo-deny and actually lint final or intermediate output binaries to detect eg dynamic libraries and such, but we haven't begun implementing in earnest yet as it's been vacation mode for the past month.

[tarcieri]

Okay, sounds good. I think it might make sense to keep cargo-audit around in the short term to see how features like call graph analysis pan out, but we can continue to advertise cargo-deny side-by-side with it as a sort of "enhanced" alternative.

We already do in places like the https://github.com/rustsec/advisory-db repo but it'd be good to add to https://rustsec.org/ as well.

[Jake-Shadle]

Just updating that I started working on a fix subcommand, but ended up having to fork some crates to add missing features and I wanted it to be able to handle more complex scenarios with multiple crate workspaces.

[Jake-Shadle]

I've merged #262 which adds the fix subcommand, will cleanup CHANGELOG and docs and prepare a post on users + reddit about this, once that's done I'll add a comment with the post here for anyone to review then I'll close this once it's all finished.

[tarcieri]

Cool, sounds good!

On the cargo-audit side we're looking at moving forward with call graph analysis. We think false positives due to the lack of such analysis is a big reason why npm audit has grown less useful with time, so it's definitely something we want to pursue.

We may eventually integrate such analysis into the rustsec crate under an optional feature if it's something you're interested in as well.

[Jake-Shadle]

Yes, I think as long as it is an optional feature that users can opt out of both at compile time and run time then that would work just fine.

[Jake-Shadle]

Closing this #300 (comment)

[tarcieri]

Note that per what I said in #300, I still think this is a possibility, but I think integrating call graph analysis is the prerequisite.