90
Supply chain attack on arrayref
(blog.rust-lang.org)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 20 Aug 2026
90 points (100.0% liked)
Rust
8248 readers
2 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
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?
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 😲😄.
Yep, it's all binaries.
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.
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.