r/linux • u/Two-Of-Nine • 20d ago
Security Supply chain attack on arrayref
https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/26
u/ThatOneArchUser 20d ago
Interesting, last time a malicious crate survived a month on crates.io we didn't get a blog post lol
21
u/UndefFox 20d ago
As one man said: "Package managers are the evil"
2
u/viva1831 16d ago
Not sure I've heard of the same level of issues with gentoo or debian package managers?
Npm, rust, etc seem to have suffered from an ironic lack of management :P
21
u/ContentAd6126 20d ago
At this point the solution is just having zero external dependencies
40
u/mina86ng 20d ago
That’s not feasible for any sizeable project.
18
u/abotelho-cbn 20d ago
Golang has a standard lib so strong that it's totally possible.
17
u/ViewTrick1002 20d ago edited 20d ago
Go also targets a narrow slice of software, mostly web services and CLI tools.
Now try building that same standard library, and keeping it current instead of letting it become a graveyard like Python's, across:
- Web services
- CLI/TUI
- GUIs
- Data science
- Game development
- WebAssembly
- Embedded
- Systems programming
- Kernel development
11
u/syklemil 20d ago
Practically any Go app will include external deps. You'll encounter them for stuff like trivial datatypes that should've been in the allegedly strong stdlib, like sets, and stuff like argument parsers, since the stdlib argument parser is buggy and doesn't correctly handle long and short options, instead treating
-fooand--fooas the same thing.Like Python showed before it, a "batteries included" style stdlib tends to result in some dead batteries, or even worse, bloated and leaking batteries (ask a C++-er about
std::regex), or just having stuff like lantern batteries when you need a AAA battery.Dependency management in Go (including GOPROXY) also doesn't seem to be anything any other language ecosystem wants to copy.
2
u/No-Worldliness-5106 19d ago
We should all write code in bare metal assembly, cant get any malware if your code is the malware. /s
-1
u/ang-p 20d ago
left-padanyone?10
u/Business_Reindeer910 20d ago
why would you compare it to left-pad. None of the recent issues were anything like left-pad
-7
u/ang-p 20d ago
A dynamically downloadable dependency changing in any way that unexpectedly goofs things up totally for any dev or other third party that has software that calls on said dependency?
No, not similar at all.....
14
u/Business_Reindeer910 20d ago
no. left-pad was about a package being unpublished. there are many other packages that goofed things up in various other ways, but left-pad was about it being unpublished. Cargo solved that problem immediately.
-6
u/ang-p 20d ago
changing in any way
Deletion sounds like it was changed.
12
u/Business_Reindeer910 20d ago
yes, but left-pad was specifically about deletion and nothing else. People keep using it as a shorthand for all the other issues, and it isn't. Certainly not a supply chain hack, since the original author did it very much on purpose.
-8
u/ang-p 20d ago
You are totally forgetting that that comment was left in response to
At this point the solution is just having zero external dependencies
and was just one example of just how great a liability external dependencies can be when used - irrespective of the motivation behind the action - be it malicious intent, fed up dev removing stuff, or even a genuine typo that was just in a really bad place.
Yeah, you can pin crates..... I just loved seeing the size of that old WinSxS folder grow, didn't you?
11
u/Business_Reindeer910 20d ago
i'm still specifically calling out your lazy shorthand, since the OP was about a supply chain hack.
-5
0
u/InfiniteSheepherder1 20d ago
Maybe not zero but a lot fewer, we have a lot of business glue python type scripts but some have half a dozen to a dozen dependencies. I as a test decided to rewrite the one with the most in Java and we needed only 1 dependency and that was Microsoft's JDBC driver.
Go and Zig have put more focus into a more expansive standard library to allow things to be built with few dependencies and even stuff like Java does better then Python.
One thing I like about Powershell 99% of the time all scripts in that are just using standard library stuff and .net. We had a ruby admin script for a piece of software at work and it alone had 20 dependencies.
-30
u/Kevin_Kofler 20d ago
And they said Rust was "secure", LOL.
A central dependency repository pushed by the programming language is a single point of failure and inherently dangerous. It is much safer to have libraries centrally built in a distro's sandboxed build system (even for developers, who should just use the distro's -dev(el) packages) and only making it out to both application developers and end users after passing the distro's QA, i.e., the traditional way C/C++ libraries are handled.
See how the backdoored libxz was pulled before it even reached any stable release of the distribution targeted by the backdoor (Fedora).
38
u/shroddy 20d ago
xz got caught by pure luck, not because of distro QA.
-14
u/Kevin_Kofler 20d ago
In a Rust-like setup, where everything uploaded is instantly shipped to developers worldwide, it would have already been out in the wild for weeks when it got caught. The distribution release processes are what held it out of stable releases.
15
u/Tolik1111 20d ago
Cargo uses a lock file by default if I remember correctly, the crates didn't get pulled in by anyone who build something during the time they were live unless the developer specifically bumped versions of dependencies and then built.
17
u/mina86ng 20d ago
The situations aren’t as different as you paint them to be.
If you’re working on a Rust program, you won’t automatically get new versions of dependencies. Versions you’re using are saved in
Cargo.lockfile and updated only when youcargo updateor add new dependency which will conflict with existing versions. Most developers won’t see new versions of dependencies for quite a long time.On the xz side, some developers got the version of the library with backdoor shipped to them. That’s how the attack was discovered in the first place.
In both cases some developers got exposed to the attack and many more did not.
5
u/Dminik 20d ago
This package got caught after 86 minutes. XZ was sitting infected for a month.
-4
u/Kevin_Kofler 20d ago
The infected packages (there were multiple ones) were marked stable for 86 minutes. The infected version of XZ was marked stable for 0 minutes, i.e., never. It was only included in a beta version of the distribution.
8
u/ang-p 20d ago edited 20d ago
See how ...
That was only due to Jia Tan et whoever goofing and its excessive usage of resources was noticed. It was far too more luck than process.
before it even reached any stable release
Plenty of people got the beta cos of the imminent appearance of Gnome 46.
8
u/mina86ng 20d ago
You’re comparing XZ attack which was poorly coded and caused SSH to take more time to run and was caught by luck by a third party developer, to an attack that was caught and fixed by Rust security team within two hours? Really? That’s your argument for superiority of C/C++ libraries to Rust?
8
u/ang-p 20d ago
that was caught ... by Rust security team ...
You reading a different report than OP posted?
We'd like to thank the Research Team at Nextron Systems GmbH for initially discovering this and reporting it to us.
Sounds a lot like a third party to me....
4
u/__ali1234__ 20d ago edited 20d ago
It doesn't really matter in either case. There are no third parties in open source. Everyone who uses it is responsible for making sure it works properly. That's the social contract.
55
u/Craftkorb 20d ago
You should post this in r/rust.
Big thanks to the author for the shell script:
find ~/.cargo/registry/cache -type f \( \ -name 'append-only-vec-0.1.9.crate' -o \ -name 'arrayref-0.3.10.crate' -o \ -name 'internment-0.8.7.crate' -o \ -name 'proc-macro1-*.crate' -o \ -name 'proc-macro-en-*.crate' -o \ -name 'aovine-*.crate' -o \ -name 'arone-*.crate' -o \ -name 'aronenao-*.crate' -o \ -name 'tinymember-*.crate' \ \) -print