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.
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.
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
As a certified C++ hater, I'm keenly aware of the mess with networking (executors,...). It's a big part of what made stop using C++. The larger was using Cargo for the first time and realizing I can start and abandon side projects at a pace never seen before.
The GUI stupidity was very fun to watch. Somehow, it kept getting worse. I think they finally stopped when there was a serious proposal to add an entire browser engine/webview into the C++ standard.
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?
This is not an either or. Sockets are shipped in almost all languages by now. Other than that, I'm thinking of Python's urllib (abstracted upon in requests) or sqlite library, Java's upcoming simple JSON parser, JDBC, or http client and the kotlinx/ktor libraries (serialization, datetime, coroutines, IO, http client, etc).
Existing libraries can be built on top of libraries shipped in core and you can still ship specific libraries for more specific use cases. It just prevents you from reaching for a library if you need to make 1-3 http requests in your application.
PS: I'd argue that almost all issues are caused by outsourcing async to libraries like Tokio, forcing a split of the ecosystem.
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.
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?
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.
no!!! not even python was dumb enough to put crypto in its stdlib! Rust has "networking" (in the sense that you can open a raw tcp socket through std), but implementing HTTP(S) on top of that would require pulling in something to do TLS which leads to..... dependencies! On OpenSSL or rustls! You've just widened the attack surface on the standard library while at the same time locking people into a single API surface that must ALWAYS be stable forever. Don't get me started on how you would approach doing anything that would need an async executor. These are not things that are suited for a systems-level language like rust's libstd. Refer to the fact that C++ didn't get a filesystem API until C++17 (and trust me, std::filesystem has some real problems still and suboptimal platform support) and they *still* haven't agreed on how to do networking.
there is no real solution to this, everything will always be pulling dependencies from *somewhere*, even if your language doesn't have a package manager. Forcing everything into the standard library is a terrible mistake because it will inevitably turn into a graveyard a few decades down the line. These things *should* take years to stabilize to make sure they're done correctly. I think people should be more conscious of what they're pulling in and very popular crates should be regularly autdited and there are ways that cargo can improve in that regard, but by god please keep libstd and libcore minimal.
Notice how I did not specify how that should be done. Also, crypto needs to be provided by people who know what they're doing, not as a random package dependency.
The point im making is that the two don't have to be mutually exclusive. Standard library maintainers are similarly just Humans too, and there absolutely are package maintainers that know what theyre doing. The de-facto library for crypto in Rust (aws-lc-rs) is provided by the AWS team and regularly get security audits; the same goes for rustls and a fair few other crates with commercial backing. I would probably trust these libraries as a dependency more than I would trust libstd if it just had a hard-dependence on OpenSSL libcrypto. Keeping the standard library surface small makes it possible to reasonably maintain and audit and for groups like ferrous systems to get it certified for safety-critical systems under iso26262 and whatnot... There needs to be a solution here other than "eehh... we trust those guys, shove it into std and we'll worry about the Implications of that in a decade.'
People do need to be more stingy about their dependencies but having one irreplaceable library to solve all the things would just add third-party dependencies to libstd and widen the attack surface while spreading maintainers thin.
We need:
Better vetting features in cargo and better protections from supply-chain attacks like a default min-publish-date.
A way to track which packages receive audits, have trusted maintainers, and follow best security practices.
Better security controls on crates.io for packages with a very large number of dependents to make this harder to pull off in practice.
Trust people, not packages. The Rust libs team doesn't have the resources to maintain all the functionality you describe with the quality people expect. I wouldn't even be against the standard library maintainers maintaining critical packages outside of std and those being marked as having some sort of "officially maintained" tag should they eventually get the resources and funding to do so, but this stuff has to be modular and replaceable separate from the perma-stability/semver guarantees of the standard library. It's one of the few parts of Rust other than the core language where if you screw it up in the right way (read: can't be fixed at an edition boundary), everyone bears the consequences forever.
You are joking right? Why do I need a 3rd party library for UUIDs, and while we are at it why do I need a 3rd party library for my RNG engine or for declaring a datetime.
Like I said in my comment there are “extra features” that a modern language should have out of the box, it should have them because you can’t write a feature without tripping over some of them and depending on a 3rd party library just weakens the language itself.
Since Rust is a low level language it is expected to be able to compile and run in limited environments such as embedded ones so the things I mentioned above wouldn’t work nicely in a non_std environment hence the idea to bundle these things in an “extra” package that you can opt-in the same way you can opt-out of std
Yes, all things that were also expected in 2012 when Rust started. UUID was added to Java in 2004.
The controversial project jigsaw in Java did let them then split tons from 'core' standard java. Minecraft for example only bundles a subset of Java, much like you're describing with "extras".
I'm highlighting this isn't a modern expectation and wondering what governance or direction in Rust prefers offloading responsibility outwards. It belongs under the foundation, that's what has the funding pipeline.
If you have a proper stdlib, chances are, you don't have a lot of dependencies
This is why you seldom hear about supply chain attacks on nuget. Not only does .NET come with a lot of stuff built in, many common packages are provided by Microsoft themselves.
Even the most popular library, Newtonsoft.json, was largely obsoleted by the .net team vastly improving their first party json library to the point where I typically see most people recommending people migrate back to the core library.
Funnily enough, the creator of Newtonsoft.Json was hired by Microsoft back in 2018. From what I remember he's not on the team that created/maintains System.Text.Json though.
I mean there are a lot of third-party packages used frequently. Things for testing, validation, some utilities like humanizer, masstransit/nservicebus, etc. Even larger ui projects like avalonia or uno are out there.
There's not a single batteries included language out there that the majority of its users don't rely on packages. Dot NET is one of the only ones I see making a big effort to improve their std library.
If you have a proper stdlib, chances are, you don't have a lot of dependencies
The attack actually refutes this point as arrayref implements functionality
that has been available in the standard library for many years via an
idiomatic TryFrom impl. If that doesn’t stop people from building
a susceptible package, what would?
It's just not true that they have the same mindset. Rust std is growing steadily, incorporating targeted features that have proved themselves popular and have been battle-tested. In the latest Rust release (today) there's another stabilized feature that they highlight can replace a certain crate with a billion downloads: https://blog.rust-lang.org/2026/08/20/Rust-1.98.0/
Other examples off the top of my head: oncelock, lazystatic, crossbeam.
I think the above comment or might be coming from a c#/java background (they would have to be insane to make this argument coming from C++ whose package infrastructure doesn't even let the user know sometimes what they are pulling in, let alone if it has a vulnerability, and whose std lib is simultaneously larger and less complete than rusts), in which case Rusts std lib looks positively spartan. There are good reasons for that kind of std lib of course, but there's still at least a point that mechanically there's less surface area the fewer dependencies you use.
I much prefer a decentralized ecosystem, and I'd rather the Cargo & crates.io teams worked on securing package management story instead.
In fact, they are working on it:
The crates.io team has been working on integrating TUF, to reduce hi-jacking.
The crates.io team has paid on-call & security staff, to handle this quickly -- 107 min. of exposure is a hell of an achievement.
The Cargo team has been working on min-age requirement, which should go hopefully ship on Nov. 12th (Rust 1.100).
Note that a min-age of even just 6h and a 107min exposure time would mean that nobody would have downloaded the rogue packages. Not foolproof, but already a good step forward.
And of course, they'll keep working on more. I'd personally love to see:
Automatic quarantining of packages on publishing, with minimum maintainer/auditor quorum; at least for any decently popular crate, or reverse-dependency of such a crate.
Complete sandboxing of any cargo command (bench, build, run, test), with each crate coming with a manifest identifying the external resources it'd need access to for each command, and an automated failure if it attempts to access anything not in the manifest and approved by the user.
This would drastically raise the bar for any sort of attack.
I mean, I don't even trust myself to write correct code, so arguably I'll be shipping untrusted code no matter what...
At some point, one has to be pragmatic. Unless you plan on writing everything from scratch yourself, your application will depend on something others wrote, and you'll need some trust in them.
Once you accept this premise, you have 2 levers:
Reducing the number of persons you trust.
Reducing how much you trust these persons.
You argue that only the first lever is worth it, I disagree. Completely.
The first lever is useful, certainly, but:
You will, in practice, most likely need a piece of functionality outside the standard library at one point or another. I certainly remember large dependency lists from the few Java projects I touched.
Rogue take-overs/... will still happen, regardless. I still remember Linux Mint's servers being hijacked, and these were professionals.
Therefore, I argue that even if you choose to exercise the first lever and reduce your trusted base, for best results you should also exercise the second lever and reduce how much you trust them as much as possible.
Or otherwise said, don't put all your eggs in the same basket.
I mean, I don't even trust myself to write correct code, so arguably I'll be shipping untrusted code no matter what... . At some point, one has to be pragmatic. Unless you plan on writing everything from scratch yourself, your application will depend on something others wrote, and you'll need some trust in them.
Exactly which is why most of your common libraries should be shipped either in the core distribution or published by trusted actors. Big companies usually have a separate security process for publishing and dealing with those issues. Like signatures which would have prevented distributing malware from Linux Mint servers. Or physical keys that get used on a system that's not connected to the net.
I am a firm proponent of "no ambient capabilities". My ideal programming language -- not runtime, language -- would see main receiving a bunch of capabilities (fs, net, clock, ...) as objects (interfaces) and have the user dutifully forward the necessary capabilities to whoever need them.
Having the capabilities as objects is great, because they can be manipulated as regular objects too. For example, you can wrap the file capability object in an object which further restricts the allowed capabilities before handing it down to a library call. Also, object capabilities respect encapsulation, unlike effects.
In such a language, you don't need to trust the matrix library you got, because you never pass any capability to the matrix library in the first place, and therefore it can't do anything but touch the existing memory.
Of course, because all other languages today have ambient capabilities, it means that any FFI/assembly usage requires its own capability. An excellent reason to pare down your usage of such libraries to the bare essentials.
Yes, but they screw up less, that's the whole point. Where do you store your API tokens? Do you use hardware tokens? Do you have any security processes other than wing it?
I agree. Every language has this problem in one way or another, it's always a question between usability or security.
I like go for this reason, since it has quite good standard libs.
It also has flags like --offline, and --frozen, which means --locked --offline, so it's possible to nerf at least simple "download & execute something in the build file" attacks, though like the other commenter says, the programmer's editor may be set up to run the offending code.
Of course, but there's a difference in getting owned instantly on install and having to execute something first. Namely that in theory you have time to inspect the package first.
But as others have said, the build.rs basically owns you at installation time
Rust's ecosystem is the main reason I don't use it. Especially if you need to target unusual or older niche architectures, most of the ecosystem is written in such a way that little endian ARM and x86_64 are the only targets supported by the ecosystem regardless of what the std library or core runtime support.
114
u/piesou 12d ago edited 12d 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:
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.