Rust has a HUGE supply chain security problem
kerkour.com
This post is part of my Summer of Rust 2024 series: weekly (or more) quickies about how to write great Rust code so you will be ready to rock at the end of the summer and find a new exciting job 🤘 Dont forget to Subscribe (Email & RSS) "If

July 2, 2024

Sylvain Kerkour writes:

Rust adoption is stagnating not because it’s missing some feature pushed by programming language theory enthusiasts, but because of a lack of focus on solving the practical problems that developers are facing every day.

… no company outside of AWS is making SDKs for Rust … it has no official HTTP library.

As a result of Rust’s lack of official packages, even its core infrastructure components need to import hundreds of third-party crates.

  • cargo imports over 400 crates.

  • crates.io has over 500 transitive dependencies.

…the offical libsignal (from the Signal messaging app) uses 500 third-party packages.

… what is really inside these packages. It has been found last month that among the 999 most popular packages on crates.io, the content of around 20% of these doesn’t even match the content of their Git repository.

…how I would do it (there may be better ways):

A stdx (for std eXtended) under the rust-lang organization containing the most-needed packages. … to make it secure: all packages in stdx can only import packages from std or stdx. No third-party imports. No supply-chain risks.

[stdx packages to include, among others]:

gzip, hex, http, json, net, rand

Read Rust has a HUGE supply chain security problem

Submitter’s note:

I find the author’s writing style immature, sensationalist, and tiresome, but they raise a number of what appear to be solid points, some of which are highlighted above.

  • TehPers@beehaw.orgEnglish
    0·
    4 months ago

    Anytime anyone mentions integrating an HTTP client into Rust’s std, all it takes is one good Python anecdote to shut that discussion right down.

    Having the standard library be stable and not try to add a bunch of support for changing standards is a long-term benefit to the language. Having “de-facto standard libs” with crates like url, http, etc ends up being better because they can evolve independently from the standard library, at the pace their respective domains evolve.

    Although, I suppose an argument could be made that url is unlikely to really evolve anymore.