Idea: When you run
cargo update, cargo downloads a list of security issues affecting standard libraries (libcore/libstd) and the compiler. Then
cargo build will warn/error when building with a version of rustc that has such a vulnerability.
Relatedly, there's an issue on
cargo audit to have it consider the stdlib.
Example from the recent past: We run
cargo update. The update downloads the info for CVE-2018-1000810. Before it is fixed, the info will say that it "affects all versions of the toolchain" and building with any version of the toolchain will warn. When Rust 1.29.1 was released then the next
cargo update would download the info that says CVE-2018-1000810 was fixed in Rust 1.29.1. Then building with any version older than Rust 1.29.1 would warn/error and building with Rust 1.29.1 or later would not.
@Alex Gaynor Not just the stdlib, but also the compiler and the rest of the toolchain (Cargo, at least).
e.g. when "fastcall" was miscompiled.
Or the recent borrow checker bugs.
(The borrow checker bugs didn't get CVEs but I argued that they should have in https://www.reddit.com/r/rust/comments/8xqrz5/announcing_rust_1271/e25yugs/)
std is how the issue is filed, but yes the issue is more general, it's the whole Rust toolchain. anyway here's the issue https://github.com/RustSec/cargo-audit/issues/46
@Tony Arcieri IMO
cargo audit shouldn't be a separate command but should instead be built into the
cargo update process, in the long term. But otherwise, I agree that that seems to be what I'm talking about.
cargo-audit is distinct from
cargo because the response from the core team, at the time, was to prototype it out-of-tree, but maybe it's worth attempting to upstream now https://github.com/rust-lang/rfcs/pull/1752
I feel cargo-audit is more than a prototype at this point, and it's about time that info got actually shipped to users - be it via cargo, github, crates-audit or all of them.
By the way, performing these checks only on
cargo update might not be the best idea. That's what
npm do, but they only work that way because that's the only place they could put that information. We could also do that on
cargo build, for example.
What people probably care most about is running vulnerable services in production, which is not mitigated by notifying on any cargo command. Some kind of pre-packaged tool that ingests Cargo.lock of a production service and pokes me if something goes wrong would be great. I'm pretty sure 90% of that is already implemented in
cargo-audit, all it needs is a way to poke me when something goes wrong - email, tweet, something. Since checking a cargo.lock is not a lot of work, I guess this could even be hosted as a service.
@Shnatsel re: looking for deployed vulnerable build artifacts, yup, I noted as much in cargo-audit #46
at one of my previous employers we had an agent which collected the Ruby equivalent of Cargo.lock from production servers and cross-referenced that with the RubySec database
and autofiled JIRA ( :weary: ) tickets about production vulnerabilities, and closed them when the responsible team deployed a version which resolved the vulnerabilities
cargo build shouldn't do networking.
Doesn't it already since it can pull down dependencies?
Nobody should use
cargo build, only
cargo build --locked.
cargo build --locked should become the default behavior. If
cargo build pulls dependencies then you haven't verified your dependencies are safe to use before running their build script.
While that's certainly reasonable, it also departs significantly from current behavior and the community's attitude towards this stuff. I'm not sure that
cargo audit shouldn't follow the same approach - network by default, but optionally locked for folks who either don't have network access, or want a reproducible build, or care more about security, etc.
Pretty sure nobody wants a network ping on every build.
cargo build does an implicit
cargo update then it would do everything that
cargo update does.
I feel like the empirical evidence - that
cargo build has that exact behavior - suggests otherwise.
I was thinking cross-referencing against a local instance of vulnerabilities database. AFAIK crates.io index is already cached locally in full
@Shnatsel I believe that's the case.
Does cargo build do a networking request on every build, or only when it needs to update dependencies/
Ah, I'm not sure about that.
I think only the latter
I guess a vuln database is meaningfully different in that the latest version is a much more appropriate version to use than whatever version we have installed that works.
For versions of source code, it's a much less important distinction.
I don't think people would accept default behavior of a network ping on every build
Yeah you're probably right.
Especially, if you think there's a possibility that a build.rs or a test is malicious or equivalently buggy, you couldn't even start the build unless/until you've got the response.
cargo audit could use a heuristic of how frequently it checks? E.g., the DB is considered stale after
n hours or something like that, unless you pass a flag to force update.
hourly database refreshes should be more than enough for non-production stuff like
More generally, cargo build could be configurable to indicate how often
cargo update should be run.
Not much difference between needing to update a dependency because somebody wrote up a CVE and the developer fixed it, vs. the developer fixed a bug without a CVE.
Especially since what's considered advisory-worthy is very subjective.
Yeah, I think that's reasonable.
e.g. OpenSSL didn't apply for CVEs for a few side-channel bugs that I would consider serious, and they're close to making that their normal policy. And BoringSSL only has one CVE even though there were multiple serious bugs, IIRC.
@Shnatsel checking against the local database is at least possible, as a copy is kept locally in