r/programming • u/Successful_Bowl2564 • 12d ago
Supply chain attack on arrayref
https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/28
u/NotSoNewell 12d ago
Huh, I just realized I don't even know how to git diff the updated Cargo packages even if I wanted to.
18
u/siera7879 12d ago edited 12d ago
There are tools to audit code and define chains of trust that allow to do that : cargo-vet and cargo-crev
And even if a lot of packages and updates are not audited, I feel like rust currently has the best tools for source code auditing, since I couldn’t find maintained tools for other languages ecosystems =/
2
u/TankorSmash 12d ago
Doesn't npm just have the diff between the lock files built in?
1
u/siera7879 12d ago
Npm diff ? From what I see it can show the update diff, but I don’t see a npm tool that allows to write and import code reviews and chains of trust. As reading every diff is very tedious, it would be better to mutualize the work.
4
118
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:
- 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.
29
u/usernamedottxt 12d 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.
54
14
u/danted002 12d 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 12d 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.
4
u/Hacnar 11d ago
See C++ and the discussions about including a gui library in their stdlib. Or networking lib.
4
u/Dminik 11d ago
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.
7
u/piesou 11d ago edited 11d ago
Pretty sure we can all agree on DateTime, JSON, HTTP client, Serialization/Deserialization, UUID, crypto, networking, and common database drivers.
3
u/EducationalBridge307 10d ago
I would not agree with this list.
At this point I wouldn't be upset if
chrono,serde, andserde_jsonwere 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
hypervs.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?3
u/piesou 10d ago
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.
1
u/danted002 10d 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 10d 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 10d 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.
1
u/tropix126 10d ago edited 10d ago
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.
1
u/piesou 10d ago
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.
1
u/tropix126 9d ago edited 9d ago
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.
2
u/pm_plz_im_lonely 12d ago
I don't know what's expected in 2026 that wasn't in 2012, but UUID ain't it.
8
u/danted002 12d ago
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
9
u/pm_plz_im_lonely 12d ago edited 12d ago
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.
54
u/AyrA_ch 12d ago edited 12d ago
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.
49
u/svick 12d ago
.Net arguably has the opposite problem: Microsoft makes almost everything, so the rest of the ecosystem is used relatively rarely.
25
u/Thorlius 12d ago
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.
11
u/smalls1652 12d ago
Funnily enough, the creator of
Newtonsoft.Jsonwas hired by Microsoft back in 2018. From what I remember he's not on the team that created/maintainsSystem.Text.Jsonthough.4
u/yanitrix 12d ago
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.
3
u/jcotton42 12d ago
vastly improving their first party json library
System.Text.Json did not exist before .NET Core 3. There was some inbox JSON before that iirc, but it was terrible and no one used it.
3
u/FullPoet 12d ago
Thats not true - theres a lot of third party packages. I think theyre are are just more complete.
So your test project will reference MS packages, TUnit, Moq and maybe something else. You can probably skip Moq.
7
u/Somepotato 12d ago
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.
2
u/EdwinYZW 11d ago
C++? It doesn't even have a package manager.
6
u/Somepotato 11d ago
True but C++ dependency management is also absolute hell
2
u/EdwinYZW 11d ago
The C++ standard doesn't have dependency. So there is no dependency hell from the language itself.
3
20
u/pp-collision 12d ago
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.
1
u/Plazmatic 9d ago
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.
4
u/the_gnarts 10d ago
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
TryFromimpl. If that doesn’t stop people from building a susceptible package, what would?3
u/matthieum 11d ago
I disagree.
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
cargocommand (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.
0
u/piesou 11d ago
That's a losing proposition. Essentially you are still gonna ship untrusted code.
1
u/matthieum 11d ago
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.
1
u/piesou 11d ago
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.
Just as an aside, I think something like this is likely the future: https://docs.deno.com/runtime/fundamentals/security/
2
u/matthieum 10d ago
Exactly which is why most of your common libraries should be shipped either in the core distribution or published by trusted actors.
I disagree, not because I don't wish for it, but because I don't trust most actors in the first place.
Big companies screw up too.
Just as an aside, I think something like this is likely the future: https://docs.deno.com/runtime/fundamentals/security/
I am a firm proponent of "no ambient capabilities". My ideal programming language -- not runtime, language -- would see
mainreceiving 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
filecapability 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.
0
u/piesou 10d ago
Big companies screw up too.
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?
2
u/matthieum 10d ago
Irrelevant: I don't maintain any popular crates, so I have had nothing to secure in the first place.
3
u/samsifpv 12d ago
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.
0
u/Sigmatics 12d ago
But what is the attack vector here? I'm not aware of any postinstall scripts for rust crates?
36
u/GuybrushThreepwo0d 12d ago
Rust has a build.rs file that runs at compile time
3
u/syklemil 11d ago
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.18
8
u/piesou 12d ago
So there's this concept called code that runs when you execute it. No postinstall scripts needed
3
u/Sigmatics 12d ago
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
-6
u/PancAshAsh 12d ago
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.
107
u/moltonel 12d ago
Longest exposure time 107min. At least this one got caught quickly.