The rust ecosystem is going to be hit by malware just like the NPM ecosystem. I have been saying it for years. They made the same mistakes or even worse mistakes because all it takes is a compromised serde to take the entire ecosystem down.
Malicious Rust crate Arrayref runs a build-time payload
181–190 of 529 posts
Re: Malicious Rust crate Arrayref runs a build-time payload
#182Rust suffers from the same faults as the JS ecosystem. Any significant crate imports hundreds if not thousands of dependencies. The probability that one of the authors gets targeted by AI-assisted attacks is just too high. Also most of these dependencies provide a breadth of features that the end package does probably not need.
A language without a large stdlib pushes this that functionality into (transitive) dependencies. I hope more language will adopt batteries included approach.
Re: Malicious Rust crate Arrayref runs a build-time payload
#183[deleted]
Re: Malicious Rust crate Arrayref runs a build-time payload
#184GitHub really needs something finer-grain then just pretending the repo never existed during these incidents. [1] The bad package version has also just disappeared from crates.io [2] with no indication its been yanked. There's no security advisory there either [3] "No advisories found for this crate." I feel crates.io was unprepared for a security incident like this since they're managing the response [4] [1]: https:…
> The bad package version has also just disappeared from crates.io with no indication its been yanked.
So, yanked crate versions do have an indication on crates.io. (Here's an example: [1]) The Rust blog post uses the word "deleted", and I'm guessing a bit here, but I think they mean that literally, and that the version here is deleted, not yanked. And I think that would be more appropriate: a yanked crate is still downloadable by cargo, if your lockfile is locked to it already; yanking only prevents lockfiles from newly automatically acquiring a lock on that version. That wouldn't be desirable in the case of a compromised crate: you don't want a download occurring at all. The tradeoff of "break those with locks on the crate" tips to being worth it.
That said, I agree with you, though: I think this state (if it is "deleted" and not yanked) should be plainly indicated on the crate's versions page. (Even better would be if it came with a link to, e.g., the blog post or a RUSTSEC so that you could find out why.) (& I think perhaps the docs for yank should point out whether or not it is appropriate in the "compromised crate" scenario, and if not, what to do instead.)
Re: Malicious Rust crate Arrayref runs a build-time payload
#185Earlier quoted context omitted.
[3] is no longer true. They're definitely not unprepared for an incident like this. It's not the first time they've done it and they published an update to their process in Feb: https://blog.rust-lang.org/2026/02/13/crates.io-malicious-cr... Not having an advisory INSTANTLY available isn't a sign of a decaying org. Chill.
> They're definitely not unprepared for an incident like this. We shouldn't need to resort to pasting `find` commands [1] into the shell from blog posts to tell if we're compromised. `cargo audit` should be reporting if these packages have been downloaded. The "What you need to do" section of the blog should be run `cargo audit` > Not having an advisory INSTANTLY available isn't a sign of a decaying org. Chill. The G…
It wasn't yanked, it was fully removed.
They did that because a yanked package can still be used. And in this case there weren't any downloads, so it is unlikely the malicious package was actually used.
Re: Malicious Rust crate Arrayref runs a build-time payload
#186Cargo desperately needs sandboxing for build.rs scripts. It’s been attempted before, but didn’t go very far¹. ¹ https://rust-lang.github.io/goals/2024h2/sandboxed-build-scr...
Sandboxing for build scripts can't work properly. If you sandbox too much, some necessary stuff can't be done. If you sandbox too little, it has no practical value.
As an easy start, how about letting build scripts read /usr, read and write a temporary build directory, have some /tmp scratch space, and be allowed to write its final output artifact. No network and otherwise isolated from the rest of the system.
I would argue that, if a build script doesn’t work in the setting, then it doesn’t deserve to be installable by a default cargo command.
Re: Malicious Rust crate Arrayref runs a build-time payload
#187I think we should be taking a more “batteries included” approach to language and library design. The entire reason we’re in this mess is because we’ve decided it’s ok or maybe even preferable if stdlibs are rail thin, rendering base languages near-unusable. I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 tot…
The Odin programming language does this! It has also decided not to provide a package manager.
Go took the same approach and ended up having to implement a halfarsed one when everyone started implementing their own.
Re: Malicious Rust crate Arrayref runs a build-time payload
#188Earlier quoted context omitted.
build.rs by design can run absolutely anything. There tons of build.rs scripts that invoke a whole-ass C compiler toolchain to build and link C dependencies... It isn't so much a question of sandboxing build.rs, as fundamentally changing the way that foreign dependencies are integrated into the rust toolchain (i.e. moving from a rust-centric system like Cargo to something more general like buck2)
The vast and overwhelming majority of build scripts are building C code, so the other solution is to move away from integrating with C dependencies to native Rust dependencies, in which case adding friction to build scripts would be less noticeable.
One of rust's strengths is it's ability to interface relatively easily with existing c code without having to rewrite absolutely everything in rust. I don't think that is something we want to give up.
Re: Malicious Rust crate Arrayref runs a build-time payload
#189Earlier quoted context omitted.
The Odin programming language does this! It has also decided not to provide a package manager.
Go took the same approach and ended up having to implement a halfarsed one when everyone started implementing their own.
Has Go not had the most secure ecosystem?
What is your critique of their approach? Is it not the case that `go get` is the only one which doesn't even provide a way for the person downloading to run the downloaded code until it is actually executed by the consuming codebase? That seems pretty sound by comparison.
I guess you're saying, "they had to" meaning they should've seen the need and provided it? I'll say this to that (imagined) take; plenty of useful software was made without it, and they got the job done when they knew the absolute most about what a good solution would need. I totally understand being annoyed at the fact that this is the story of every evolution in Go, but I genuinely think they're picking good implementations when they decide on them.
Re: Malicious Rust crate Arrayref runs a build-time payload
#190Doing software development outside of strict containerization, at the very least, looks increasingly prone to disaster. Yes, we can argue about the culture of package management (as some of us have with especially npm from day one), but it's done, and your colleagues or AI sidekicks cannot be trusted not to download whatever and try to build and run it. All you can do is limit the effective blast radius.
Proper and easy to use support for sandboxes at the OS level, or better yet capabilities, seems like the only long term solution. Many things I run I want to limit to r/w a single dir, and to have to request permission to make network calls.
Two problems with this:
1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust.
2. Even if there were, if you’re compiling untrusted code then why would you trust the built output?
If you’re building the create then I’d argue that any preventative steps afterwards is akin to closing the barn door after the horse has already bolted.