NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
18.28k stars 14.26k forks source link

Vendored crates with known vulnerabilities in Rust packages #141368

Open sternenseemann opened 3 years ago

sternenseemann commented 3 years ago

The vulnerability report below was generated by nixpkgs-crate-holes which extracts the Cargo.lock file of each package in nixpkgs with a cargoDeps attribute and passes it to cargo-audit using RustSec's advisory-db at d29205a.

Feel free to report any problems or suggest improvements in this Discourse thread or via email! Tick off any reports that have been fixed in the meantime.

Note: A vulnerability in a dependency does not necessarily mean the dependent package is vulnerable, e. g. when a vulnerable function isn't used.

398 of 665 checked attributes have vulnerable dependencies.

Generating Cargo.lock vulnerability reports If you have a checkout of [depot](https://code.tvl.fyi/about/), you can generate this report using: ``` nix-build -A users.sterni.nixpkgs-crate-holes.full \ --argstr nixpkgsPath /path/to/nixpkgs ``` If you want a more detailed report for a single attribute of nixpkgs, use: ``` nix-build -A users.sterni.nixpkgs-crate-holes.single \ --argstr nixpkgsPath /path/to/nixpkgs --arg attr '[ "ripgrep" ]' ```
nixos-discourse commented 3 years ago

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/vulnerability-report-for-vendored-rust-crates/15462/1

newAM commented 3 years ago

cargo-embed is secure with the current feature set used in nixpkgs: https://github.com/NixOS/nixpkgs/blob/615989e078ae8b21a948d3d1c05b40da730ffb4d/pkgs/development/tools/rust/cargo-embed/default.nix#L28

All 3 vulnerabilities come from dependencies that are added when built with the sentry feature (used to report crash data).

Edit: cargo-flash is also secure for the same reasons.

newAM commented 3 years ago

cargo-deadlinks is updated in #141454

06kellyjac commented 3 years ago

Thanks for doing this @sternenseemann Would it be possible to get this as separate issues and pinging maintainers going forward like the vulnerability roundup?

If I wasn't keeping a regular eye on the matrix security channel I wouldn't have spotted this, so it'd have the benefit of notifying maintainers without the issue of pinging everyone and having everyone commenting updates in the same issue

Working on getting agate updated upstream (if it takes more than a couple days to be merged and released I guess I'll patch it in). There's a new release of deno so I'll check that's resolved it. I'll also check bat.

Edit: deno vulns are resolved by #141433

sternenseemann commented 3 years ago

Would it be possible to get this as separate issues and pinging maintainers going forward like the vulnerability roundup?

I'd like to keep it a single issue at a time, since it's much easier to deal with (no need to interact with the GitHub API…) and there are quite a lot of false positives. For the same reason I didn't want to ping maintainers just yet, but I was thinking of whitelisting maintainers to be pinged?

06kellyjac commented 3 years ago

That's reasonable. I'd be happy to be on the list if you add that.

If it could be marked next to the packages that'd help me jump to the ones I maintain. If that's too much effort I can always crossreference against repology

KamilaBorowska commented 3 years ago

python3{8,9}Packages.skytemple-rust can be marked as solved.

turboMaCk commented 2 years ago

@zwilias Are there any plans to patch elm-json?

zwilias commented 2 years ago

@turboMaCk I'm traveling right now but I'll get on it in a couple of days. Thanks for the ping 👍

zwilias commented 2 years ago

@turboMaCk some delay, but v0.2.12 was published and got rid of/updated all dependencies that were causing warnings here 😄

turboMaCk commented 2 years ago

sounds great. thanks @zwilias

mweinelt commented 2 years ago

rust-cbindgen is using smallvec 1.8.0, so marked resolved

sternenseemann commented 2 years ago

Updated report, split into two comments since it has become too long for GitHub's comment limit


The vulnerability report below was generated by nixpkgs-crate-holes which extracts the Cargo.lock file of each package in nixpkgs with a cargoDeps attribute and passes it to cargo-audit using RustSec's advisory-db at 2875efb.

Feel free to report any problems or suggest improvements (I have an email address on my profile and hang out on Matrix/libera.chat as sterni)! Tick off any reports that have been fixed in the meantime.

Note: A vulnerability in a dependency does not necessarily mean the dependent package is vulnerable, e. g. when a vulnerable function isn't used.

sternenseemann commented 2 years ago

Here's an updated report. Sadly the report now exceeds GitHub's comment limit by a factor of 6. Not sure what's the best approach for the future.

Edit: Apparently, it did work, GitHub's UI is just uhh interesting.

sternenseemann commented 2 years ago

672 of 825 checked attributes have vulnerable dependencies.

Generating Cargo.lock vulnerability reports If you have a checkout of [depot](https://code.tvl.fyi/about/), you can generate this report using: ``` nix-build -A users.sterni.nixpkgs-crate-holes.full \ --argstr nixpkgsPath /path/to/nixpkgs ``` If you want a more detailed report for a single attribute of nixpkgs, use: ``` nix-build -A users.sterni.nixpkgs-crate-holes.single \ --argstr nixpkgsPath /path/to/nixpkgs --arg attr '[ "ripgrep" ]' ```
nixos-discourse commented 2 years ago

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/packages-marked-as-broken-should-come-with-an-explanation/19187/9

aktaboot commented 7 months ago

it would be nice to have an updated version of the list if possible. I failed trying to generate one

nixos-discourse commented 1 month ago

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/state-of-haskell-nix-ecosystem-2024/53740/8