Vulnerability Report for vendored Rust crates

Following a suggestion by @qyliss, I investigated checking the Cargo.lock files of the various buildRustPackage derivations we have in nixpkgs against RustSec’s advisory-db. Using cargo-audit and a bit of glue code, this turned out to be not too hard.

The result is https://github.com/NixOS/nixpkgs/issues/141368, in case you maintain Rust packages in nixpkgs, consider following up on these warnings.

Of course this type of checking is prone to a lot of false positives: A vulnerability in a dependency doesn’t necessarily mean the dependent package is vulnerable as well. The report at least seems to confirm the concerns of “The modern packager’s security nightmare”: Cargo’s lock files and vendoring have lead to for example multiple vulnerable openssl versions coming up in the dependency graph of packages — even though these have been long patched in our normal openssl package.

Feel free to report any issues or suggest improvements in this thread. Additionally I’d be interested in preventable false positives.

17 Likes

I noticed a recurring pattern after manually triaging some of the crates; cargo features play a large role.

Many of the openssl-src vulnerabilities do not apply for nixpkgs because vendoring openssl is often exposed as a non-default feature flag (e.g. cargo-outdated, cargo-generate). Some crates do not even have any vulnerabilities after accounting for disabled features (e.g. cargo-flash, cargo-embed).

Applying the feature flags to the crates to determine which dependencies should be included in the audit would help a lot with the signal to noise ratio. Regardless, this is very useful information, nicely done!

6 Likes

Indeed, I’ll add an extra check for openssl (probably by looking at what the resulting binary links against), cargo features in general are maybe a bit trickier, I’m not sure how we can account for those without a ton of effort, but I also haven’t looked into it yet, really.

1 Like