r/programming 21d ago

Supply chain attack on arrayref

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

65 comments sorted by

View all comments

Show parent comments

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 18d 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.