These build scripts should really be restricted. For any language, not just Rust.
this post was submitted on 20 Aug 2026
88 points (100.0% liked)
Rust
8237 readers
25 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 3 years ago
MODERATORS
That would be good but it's not a magic solution to this problem. They would just move the exploit to runtime. Yeay you don't get hacked if you compile and never run your program.
You can counter that there are some situations where the program is run sandboxed, e.g. if you're compiling to WASI or microcontroller firmware or whatever. But those are a tiny minority of cases.
Good point. But hey, at least CI would be safer if nothing else and we'd raise the bar.
There have been discussions in the past around sandboxing build scripts, but until that day comes (if it does), I think there could at least be a prompt to approve build scripts for individual package versions. Several JS package managers do this now, and it helps.
Ya, this type of design (npm, Rust, Go?) seems crazy to me. I’m glad I use Java in my day job, haven’t run into any build script attacks yet.
I guess Rust probably chose it so you can build easily on any system? But why can build scripts download stuff an me inject it?
It's necessary to integrate Rust with other languages (to build source code in other languages, generate some bindings, etc). Otherwise you will have to make Cargo understand every other build system in existence, and stay compatible with them forever.
Ideally this should be heavily audited and allowed only when it's really necessary.
Almost all non-trivial projects in any language have external dependencies. And those dependencies have to come from somewhere.
I also wonder what you think Maven/Gradle/...etc job is.
Gradle and Maven create static build artifacts, they do not dynamically run 3rd party build scripts. And it is uncommon (though not impossible) to use dynamic version targets.
I’m ~~it~~ not saying it’s an impossible attack vector Java, but I haven't seen it yet and I’ve seen it a couple times with Rust and countless times with Javascript. The Javascript ones now use your credentials to publish even more malicious build scripts, so it spreads like a virus.
In Java world package managers and package registries work with prebuilt libraries because for JVM bytecode it's sufficient. And if they have native dependencies then they include compiled .dll or .so files that are built on developer's machine. This makes things simpler but has its own drawbacks (these dependencies work only on architectures and OSes developer thought of, there is no guarantee that the library will be compatible with user's environment, etc).
In Rust world everything is built from source, including native dependencies. Thsi makes build process much more complicated and necessitates running code on user's (developer consumes the library as dependency, not end user) machine to build everything that's not Rust.
I just wanted to ask, how do they build C libraries in JAVA world? And if the answer is they don't, they just ship binaries, then that's infinitely worse. And you just confirmed that's the case 😲😄.
In reality it very rarely happens that native binaries are needed for Java. I’m not even sure what libraries might use them nowadays - I would guess mostly commercial closed source.
I don’t think it’s “infinitely worse”, but it does mean you require builds for whatever platform you are on or you need to manually build it from source as a separate project.
JVM, ELF, Mach-O,.... binaries are infinitely worse when the attack vector is "compromised dev machine".
I'm not sure how anyone would even try to argue against that.
Yep, it's all binaries.
It appears I wasn’t hit, though I easily could have been, as I installed some Rust-based Python packages recently.
I keep telling myself I’m going to containerize more projects, but it’s getting ridiculous now… TBH, maybe more Linux distros need to operate on a more strict “containerize everything by default” principle, as this is going to keep happening.
It appears I wasn’t hit, though I easily could have been, as I installed some Rust-based Python packages recently.
I easily could have been
If you're using good projects that have Cargo.lock checked in (should be about everyone nowadays), an do the right thing using --locked with cargo install, then not really, It wouldn't have been easy.
Unless both an upstream (auto-)merging a bot PR updating to the malicious version (bad), and you installing that upstream (spectacularly unlucky), happened to coincide within that 86 minutes the malicious crate was up (39 minutes if advisory-db was hit at any step), which is almost impossible, but more importantly, fully traceable and investigable at the ecosystem level. And if we are talking released versions only, then the upstream would have had to cut a release and publish it also within that window.
But yes, this is a historic first, a malicious publishing of a real crate with real dependants.
Edit: I checked all arrayref dependants, and no crate published within the compromised window. No crate explicitly depends on >=0.3.10 (forcing the malicious version). And no crate published after the incident (potentially indicating fixing an earlier mistake) except for a couple of no-name blockchain crates that don't even have source repos.
Well that’s the thing that scares me; I installed some Python packages (via uv) that compile Rust code upon installation.
I don’t know what they do, or how pip handles it. I had to go and dig, and figure out how they install packages and what the original projects use.
An atomic distro + toolbox may be what you’re looking for, unless you have pretty specific baremetal requirements
pretty specific baremetal requirements
I do, for some things, unfortunately.
I think Firejail or good old systemd sandboxing would be massive improvements though; I just need to invest the energy in setting them up.
The would protect against malicious code running on the Dev's computer (which AFAICT is the case here), but not against the code created using the infected library running on users' computers. And honestly, seeing the regularity of supply chain attacks in recent times, I think we need to find a better way to work with supply chains going forward. Although I admittedly don't have any solutions myself, tbh.
The model of stable Linux distros, particularly Red Hat, Debian, and Ubuntu is impressive in that they only ship cherry picked security updates, and don't ship general updates overall, often even forgoing bugfixes. They are extremely resilient against supply chain attacks.
The XZ utils backdoor, for example, did not make it into either of those three distros. That's why I hate when it's compared to programming langauge specific supply chain attacks, because there is a big different. With Debian/RHEL, you have 4+ years to catch a supply chain issue, rather than whatever your dependency cooldown is.
And then, the lack of any non-security changes means that the system behavior is stable enough to base software on it that automatically receives security updates to libraries it is using.
This is why enterprises like RHEL so much. For so many institutions, manually managing updates is a cost they are unwilling to, or straight up unable to handle. The idea of manually doing updates, or bypassing cooldowns in order to get a fix for some critical CVE, is way more expensive than it's worth at scale, especially for institutions that aren't going to actively take advantage of new features, like so many slow moving government entities or so many non tech focused corporations.
I like the model of Rust, and believe it is the future of systems programming, but I am intensely frustrated with the way it is tied to an ecosystem that is extremely sloppy about supply chain security. The Linux kernel and Firefox may use Rust, but they don't actually use the Rust ecosystem, they copy all crates they use into their own tree, and then cherry pick and review changes, or maintain the software themselves entirely. All Rust code Linux/Firefox use is owned by themselves, although I think that such a model is only possible due to the development resources they have.
I'm still talking about programming language specific supply chain attacks, I'm just talking about those where the malicious code targets the user's computer. Especially in a language like rust where everything is linked statically, a simple update of a library can bring in malicious code, and generally a change such as "updated library X to Y.Z" will not be analyzed as slowly as code changes from the project itself. And while I personally prefer the concept of stable distros, the whole concept of stable distributions is that the software was used for an extended period of time before that, and you don't want those users getting malware, either - so that's not really the solution to the problem IMO.
the whole concept of stable distributions is that the software was used for an extended period of time before tha
Not quite, the whole concept of these ultra stable distros is that they take a version of the software, and essentially pin, it, cherrypicking mostly, or only security changes as updates. The version of the software that is selected, can be, and usually is from a much newer version of the software overall.
Because of this, Debian and Ubuntu have an interesting pattern, where each one doesn't universally have older packages than the other. Instead, a new Debian release comes out, it has newer packages, then a new Ubuntu release comes out, and they alternate.
Anyway, during the process of releasing a new stable distro, the programs are libraries are assessed, and then tested a bit before being included. In theory, if you had enough manpower, and you were fast enough, you could probably pin close to the current latest version of things, and then have those in your stable distro, even if they have only been out for a short period of time.
The idea of "program version has been released for 2 years, now let's include them into a stable distro", is not how they actually work. Instead, the pinning and then security updates model, deduplicates a lot of work, because now you only assess the security and quality of the programs to be packaged once, instead of continuously every single update.
It's not about eliminating bugs by using well tested programs. Stable distros are about ensuring the stability of the behavior of the system. The same set of, of predictable bugs, rather than a constantly changing set of them.
If you use a stable distro as your programming language supply chain, you essentially don't have to deal with security updates in dependent libraries, or worry about supply chain security. Any dynamically linked language is able to do this, but my frustration with Rust is that this is not an option, which is something I really hope changes in the future.