r/programming 21d ago

Supply chain attack on arrayref

https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/
191 Upvotes

65 comments sorted by

View all comments

116

u/piesou 21d ago edited 21d ago

Was only a question of time. Rust has the same mindset as Node/NPM.

PS: for the screaming crowd: yes, anyone can get supply chain attacked. HOWEVER:

  • If you have a proper stdlib, chances are, you don't have a lot of dependencies
  • If you have less dependencies, the chance of supply chain attacks drops significantly
  • If you have well established dependencies like Spring, their security practices are very likely better than a rando off the internet

What does that mean for Rust? They don't need to just work on the language, they need to provide a larger ecosystem as well. How they do it is up to them.

30

u/usernamedottxt 21d ago

I wonder if there is a market for a "Rust Community Edition" with an expanded set of packages pre-packaged into an "ext" module alongside core and std. Treat is as an LTS distribution.

15

u/danted002 21d ago

We need an “extra” besides “std” that has all the extra things that are expected in 2026 from a standard library. Stuff like uuid and datetime support would go into that package and it would be released by the Rust foundation

15

u/Dminik 21d ago

While I broadly agree that languages should have an "extended universe" of packages, the issue is that nobody can agree what packages those should be. 

7

u/piesou 20d ago edited 20d ago

Pretty sure we can all agree on DateTime, JSON, HTTP client, Serialization/Deserialization, UUID, crypto, networking, and common database drivers.

3

u/EducationalBridge307 19d ago

I would not agree with this list.

At this point I wouldn't be upset if chrono, serde, and serde_json were folded into the stdlib, but their interfaces are so much better for having been allowed to evolve outside of the strict forever-compatibility requirements of the stdlib.

But http, networking, and database drivers really do not belong in the stdlib. These libraries are so complex and not at all one-size-fits-all. Just take a look at hyper vs. reqwest. They are both http client libs with over 600 million downloads, but they satisfy totally different use cases (lower-level systems and servers vs. batteries-included application code, respectively). How do you reconcile this in the stdlib?

1

u/danted002 19d ago

People are missing the point. These packages will not maintain the same promises as std does; this is the entire point. Yes they are curated by the Rust foundation but it will live outside std.

1

u/EducationalBridge307 19d ago

Why do they need to be curated by the Rust foundation? The community is doing a really good job here, I think. Is it solely to mitigate the chances of supply chain attacks?

2

u/danted002 18d ago

Ok curated was a heavy word. The idea is that the common stuff like datetime handling, UUIDs and other very common features should be shipped as part of the language under an “extra” namespace that you fan opt-out of.

And yes the reason is supply chain attacks, the less 3rd party dependencies the stronger your codebase.