Aren't there any efforts to bring Rust's dependency number down?

Deno uses blessed packages instead of a built-in standard library: https://deno.land/std/

But that's a different situation.

I know it might not be obvious, but it is not Rust's fault that you use wrong dependency for task at hand.
Use getrandom and you get only target dependent stuff to generate number using OS APIs
Problem solved?

To improve dependency hell we must strive to hygiene ourself first

Moderation note: Discussion of namesquatting is off-topic for this thread in particular. More generally, it has been discussed many many many times. Please search the forum and irlo. The next step here is to write an RFC in collaboration with the crates.io team to propose a change in the current policy.

The article's quote of 70% seems to come from here, which in turn points to another Google Security Blog article which includes a 2019 pie chart with a 60% number, but that also references a third article where the 2018 chart looks more like 80%. Not the most consistent figure, but doesn't seem to be parroting either.

1 Like

I think the clause about doing simple things is the crux of the issue. There are many languages that will do very sophisticated things right out of the box -- the languages were designed to be turnkey for the time in which they were created. Rust is a fairly low-level language that supports some very nice abstractions that make checking correctness much easier. The crate system works very well. While it suffers from the same kinds of problems seen with any 3rd party library systems, its convenience greatly reduces the pain of experimentation, auditing, and version locking.

Some things that seem simple actually are very complex, and require many moving parts. Two examples are the web server and the text editor. Even filesystem I/O can be fairly complex if portability is important.

My 2 cents -- The more complex the code base, there more tradeoffs there will be between convenience and reliability.

I’ve only skimmed this thread, but I’ve felt the same way as OP and I think I understand some of the concerns expressed by people in this thread.

  1. Are all my dependencies licensed such that I can use them in my project? If there’s a few holdouts where the author didn’t specify the license, especially dependencies of dependencies, that could be problematic
  2. Do I trust the code I’m including in the project? Given the barrier of entry to cargo publish is low and the aggregate number of people involved is high.

For (1) there’s cargo license, and it might be helpful to nag if you publish.

For (2) I think a solution might be to have a system for crates to be ‘verified’ which basically means a trusted group of people has done a code review and/or run through a basic infosec checklist (eg do only active maintainers have write access, do they check all PRs, do they at least know how to safely manage passwords (even though actually verifying they follow it might be practically impossible), do they have a reasonable api migration strategy and respect semver’s expectations, etc).

But I think the ‘verified’ solution, while details might need to be worked out (how do we help add trust without creating undue liability for the reviewers, who reviews the reviewers and how this chain of trust is established in general, keeping it consistent and objective) would be easily understandable and help mitigate some of the concern.

That's exactly what cargo-crev is.

5 Likes