For a decently-sized application it’s not uncommon to indirectly depend on more than hundred crates. Running
grep -c package Cargo.lock on my rather small webapp yields a count of 151, for example. Most of those crates are indirect dependencies, and I suspect that this amount of dependencies, plus the common practice of version pinning, may slow the propagation of security updates down to the point where it becomes a problem endemic to the ecosystem. Here’s an example.
Assume that my application
W depends on crate
X, which depends on crate
Y, which depends on crate
Z. All crates are post-1.0 and pinned by
MINOR version from the previous crate.
If a security issue is disclosed to the author of crate
Z, they need to decide whether to backport the patch to the last
n minor versions:
- If they do, a simple
cargo updatefor my application
Wwill suffice to recieve the update.
- If they don’t, I need to wait for the maintainers of crate
Yto update their
Unfortunately I’m depending on open source libraries where nobody gets paid for their work. This means that the maintainer of
Z is less likely to backport the patch to other
MINOR versions, only the latest version gets a
PATCH release. The maintainers of
Y are less likely to update their dependencies either, because they do all of this in their freetime as well. This is a social problem though, and people are just getting started writing about this issue.
Assuming there will be no backports for this patch, a thing the author of
Z could do in this situation is to yank all vulnerable versions of
Z. However, this doesn’t actually prevent anybody from compiling existing applications with this vulnerable dependency, but at least it prevents writing new ones. But even there it is not an entirely correct thing to do, as even a critical security issue may affect only small parts of the crate’s public API.
Instead I’m proposing a “soft-core” version of the
yank command, let’s call it
defame. It is essentially CVEs, but integrated into the package index.
- It would mark (by default) all existing versions on crates.io of the given crate as insecure, perhaps with the possibility to attach text that describes the vulnerability in detail.
- Cargo would refuse to compile such versions without an override switch. This override switch could be defined in the
Cargo.tomlof any crate that depends on it (directly or indirectly).
With those annotations, one could e.g. build tooling that automatically notifies me, the application developer, about security issues in my dependencies.