I am stepping back from maintaining ‘cargo audit’

TL;DR: I will no longer be actively working on cargo audit and the RustSec security advisory database. I will continue working on my other Rust projects and contributing to the Rust ecosystem. Maintenance of cargo audit and its database will be carried on by the other maintainers.

The catalyst

Any command that goes through Rust’s build system, Cargo, can execute arbitrary code. This applies to any command starting with cargo.

This is a pretty reasonable thing for a build system. After all, you’d expect the same from calling make or gradle or pretty much anything else.

It is not so reasonable when you consider external plugins for Cargo such as cargo audit. Similar programs like osv-scanner or trivy do not execute arbitrary code from the repository, so why should cargo audit?

So what do we do?

The exact details of the issue are not really relevant here, but you can read my article about it if you’re curious:

Do not run any Cargo commands on untrusted projects

The important bit is that there are three ways to resolve this issue:

Change the behavior of Cargo

While the Cargo team agrees this is desirable in the long run, this is also a breaking change for existing users that may be using these features for legitimate purposes.

And since this is a breaking change, it will need to go through a lengthy deprecation period first. So any solution here is not going to arrive soon enough, even if implementation on it started today. Plus there are always people out there running years-old versions of Cargo.

Document the issue and pretend that this solves it

So should we just accept this and document that cargo audit cannot be run on untrusted code?

Most people are running cargo audit either on CI, which is well equipped for running untrusted code, or on their own projects they trust. And yet, I’m certain that someone, somewhere, will quite reasonably assume that cargo audit isn’t different from other vulnerability scanners, and run it on untrusted code without sandboxing, and get pwned.

I even wrote a custom binary format parser to make its binary scanning 100% memory safe and robust, so it feels weird to get an arbitrary code execution vulnerability from a far simpler source.

Rename ‘cargo audit’ and migrate all users

So should we rename it to something like rust-audit and tell all users to migrate?

But if we’re migrating users anyway, does it have to be a migration to the new name of the same tool? Maybe it’s time to just port the remaining “special sauce” like binary scanning and automatic fixes to something else, like osv-scanner, and just migrate people to that?

Why do we even have ‘cargo audit’?

When Tony started cargo audit eight years ago, the very concept of an actually machine-readable vulnerability database and a tool that could automatically check your dependencies against it was novel. There was literally nothing else that could do the job of cargo audit.

But in the last few years the rest of the industry has finally caught up. There is now a single machine-readable format and aggregator (OSV), a bunch of tools that pull data from it, and even a competing vulnerability database under a permissive license that imports our data and exports all its data to OSV (at least for now).

cargo audit still has special sauce, to be sure:

1. It generates the Cargo.lock file if it’s not present or out of date. But it calls into Cargo to do it, so that’s unsafe on an untrusted project.
2. It can scan even binaries built without cargo auditable and recover an (incomplete) list of dependencies by parsing panic messages.
3. You can run cargo audit fix to try and automatically upgrade your vulnerable dependencies to versions with the fixes.
4. It will notify you about unmaintained dependencies that do not receive security updates.

But 1 through 3 are features that I’ve implemented (at least in their current form), and the code is quite straightforward. There is no reason why other tools, even ones not specifically built for Rust, could not adopt them.

And 4 has been a controversial feature. Some people love it, some people hate it. cargo audit is configured to only show a warning by default and not cause CI to fail, but lots of people use a Github action that treats them as an error, and get upset when unmaintained crates break CI. This cannot be easily fixed because, ironically, that Github action is unmaintained. Even if this doesn’t fail CI, it can still put unwanted pressure on people.

Given that this feature is not unambiguously and universally great, I wouldn’t be too sad to let it go.

The costs of maintenance

Unlike some of my other Rust projects, cargo audit requires ongoing maintenance to keep up with the changes to Cargo and the ecosystem.

And that’s not mentioning the work and stress of maintaining a database of security advisories. Every single one should be reviewed and published promptly, any day of the week, any day of the year, and contain information that is accurate and actionable.

Oh, and did I mention all of this has been done by only a small team of volunteers for years now?

cargo audit never had any funding (aside from that one time when Google paid me to bridge the advisory database to OSV. Thanks, Google!), and the volunteer maintainers are spread thin as it is. I maintain way too many Cargo plugins and make other contributions across the ecosystem. Tony maintains so many crates that just listing them takes over 10 pages. Alex started Rust for Linux and maintains Python’s cryptography package, among other things. And Alexis has multiple important projects of his own, and also seems to be the only one of us who actually has a life.

Is it worth it?

cargo audit is not as crucial and irreplaceable as it used to be. It still has features that are completely unique, but those are relatively straightforward to implement and require barely any maintenance.

The real maintenance hog is the boring parts, which are now implemented perfectly fine by multiple other tools. And sinking a lot of time and effort into maintaining yet another implementation that isn’t meaningfully better than others just so that we could add a thin layer of unique features on top doesn’t seem like a good use of anyone’s resources.

And it’s difficult to keep up with the times when everyone is spread so thin.

For example, right now the database of cargo audit is not as complete as that of some of the other tools. The Github database pulls data from us and exports to OSV, but we didn’t yet wire up import of data from the Github database. Alexis already did most of the work on that and I meant to get it over the finish line, but never did because most of my time goes into urgent maintenance.

Now that cargo audit is not vastly ahead of the industry anymore, I think it’s time to share the special sauce around, take a step back, and focus on things that remain genuinely novel or that the industry is willing to fund. So that’s exactly what I will be doing.

And if you disagree with my assessment, the remaining maintainers could definitely use some help. You can get in touch with them on Zulip.