> 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.)

[1]: https://crates.io/crates/aes/versions

[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.

> GitHub really needs something finer-grain then just pretending the repo never existed during these incidents.

Google should read this too. They simply remove Android apps and Chrome extensions without a single word. No page explaining why they removed it.

This is exactly what PMG is designed for ie. install/build time process level sandboxing. It currently doesn't support cargo, but I believe the challenges are same.

Here is my learning building PMG:

Sandboxing is good when the workload is predictable, and the goal of sandbox is to guard against exploitation of vulnerabilities, like sandbox protecting chrome tabs (renderers). But unfortunately build scripts are not predictable, at least not in npm/pypi world and I have seen build scripts doing weirdest of the things which is no different from malware. When popular packages do weird things, build breaks and users end up turning off the sandbox. This is a perpetual problem to deal with while building sandbox (or any least privilege solution) to protect unbounded workloads.

https://github.com/safedep/pmg

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)

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.

I mean sure, but anything the build script could do, the build artifact could also do, That is to say, if you don't trust your source why do you trust the thing it compiles into?

Sandboxing just build.rs would only be be a minor inconvenience for the attacker, nothing more. The attacker can always as easily compromise the binary you build and as soon as you run it (e.g. in a test) you are owned.

It would be a big pain for many that are in the unfortunate position to really need build scripts, though.

Never going to work. Crates must be audited for behavior before use.

https://news.ycombinator.com/item?id=49374811

(Oh and btw, proc macros also run arbitrary code.)

Here's a suggestion, do you think it could be this simple? If you write a package-manager, don't execute any of the downloaded code in an automated fashion. No hooks, no build-time metaprograms. If your language _needs_ metaprogramming to function, it's a huge secondary issue that I don't know how to solve. You can try to make a meta-program annotation which disables side-effects, but the metaprogram ultimately must write memory which expands the amount of code generated. All risk is introduced when the person downloading cannot preview the content in a safe place.

This is spot on. I am extremely uncomfortable with the large number of transitive dependencies that end up in pretty much any non-trivial rust application. No amount of memory safety will save us if a tiny, ubiquitous library that nobody scrutinizes because it’s nested eight layers down the dependency graph gets compromised.

I think Go apps tend to have better dependency hygiene because the language has a better standard library, which results in better culture around dependencies.

I also think it’s frustrating that both cargo and npm totally ignore the decades of prior art from Linux distributions that have figured out good ways to improve dependency management. We’d be in better shape if there was a community curated subset of known-good dependencies that are release-managed together that the broader ecosystem could build on, sort of like Ubuntu having “main” and “universe”.

This was actually the main thing that put me off of Rust. I get the argument for a small std lib. I just also don’t agree it’s worth it. Go seems to handle having a batteries included standard lib just fine.

Rust has a sizable and well featured standard library at this point. I think it would be absurd to claim that the base language is "near-unusable" if you are using it for system programming, which is its intended use case.

Huge standard libraries make sense for Java, Go, Apple platform etc. because they are developed by giant enterprises that can manage the overhead. Thinner modular systems are a more natural fit for open source development.

The Odin programming language does this! It has also decided not to provide a package manager.

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.

minimum-release-age

My experience has been that it has a major advantage, in that freeze + offline actually work properly. You can collect the dependencies you need once, put them in version control and never ever talk to remote registry again

A language without a large stdlib pushes this that functionality into (transitive) dependencies. I hope more language will adopt batteries included approach.

Yes, the lack of a language package manager for older programming languages is a feature.

I think this is an attractive chimera, but will never be popular and will only be used much in specific domains.

The thing is, trust is a massive optimization. If you believe code from X is competently made and not malicious, you can accept that code without any additional overhead. (Building trust is a significant effort, but trust begets trust, so there's a resonable path from starting small to scaling.)

It's not that these mechanisms that require less trust (none of them eliminate it, BTW, when you examine them) can't work. It's that they'll inevitably be outcompeted by trust-based systems (in most domains).

E.g., compare the effort of creating a new, full featured, general purpose language, promoting it, building and maintaining all the tooling and documentation around it to support it, etc to the effort of creating and maintaining a curated package repository of trusted packages (and/or adding trusted code to extend the standard library) for existing language X.

(It's not clear to me you could provide enough value from a new language focused on effects that you could convince any but a few from adopting it at all, even if it dropped from the sky fully formed with all tools, docs, etc. in place from day one.)

> It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles.

It's not the only way. You can sandbox processes. I think sandboxing is the much more reasonable approach, because in the end of the day, there are still closed-source software products where you can't demand that the manufacturers use certain language safety features.

Some shameless self promo - I'm working on one!

https://hale-lang.org/proof/

https://github.com/insanitybit/witchy

This is why I'm building this language. It's capabilities based. Build scripts can't just do whatever the hell they want to, everything is auditable, and it layers its sandboxing.

It's for fun and anyone looking should understand that this is AI driven building with human driven design, but the goal is to demonstrate.

I think the only language that's used in production where malicious dependencies can't do arbitrary effects is https://roc-lang.org - but it's a pre-0.1.0 language and as such its production usage is extremely minimal for now.

I have been working on a cross platform way of sandboxing without a VM:

https://github.com/brianv0/formwork

Can you explain how an effect based language helps here? Also to note filesystem access can allow network access on many systems and also the other way around.

Why does every build have the ability to run arbitrary code by default in the first place? That seems like something you should opt into only under very specific scenarios and even then it should probably be built around a WASM sandbox or microVM (as the parent suggested).

More than that, we need capability-based languages. No capability passed to it, no permission.

MicroVM this, effects that --- can we discuss security without needing to invoke bay area buzzwords?

The idea is "least privilege", and we desperately need it in computing. The precise technical mechanism we use to achieve it is less important than committing to the idea that a dependency doesn't run with full privilege of its host program and an install script doesn't run with full privilege of the programmer.

The original Linux seccomp is old enough to drink. It's always been possible to do things like expand macros in a no-IO environment. Nobody's bothered to do it over the past two decades. Why would anyone bother in the next two decades?

As long as your versions don't have any security issues...

There's a reasonable solution to this. Tools like `cargo-audit` can tell you if a crate has security issues and guide you towards an update. You don't have to blindly update all dependencies this way.

I mean, yes, update your dependencies. But probably after a week or so after they've been release and tested by the first penguins willing to jump into the ocean.

What purpose does “undeniable” serve here? This tips over into hyperbole, in my opinion, whereas “it’s foresight” is much simpler and stronger. YMMV.

There was a recent talk which explored this question (Dependency Cultures, by Richard Feldman):

https://www.youtube.com/watch?v=E82ly38YEEQ

Summary: it's cultural. Rust likely inherited the practice from Nodejs, who inherited it from Ruby. I think in Rust online spaces in particular there is also this undercurrent of "you're not smart enough to use certain parts of the language, so download libraries that handle that stuff for you."

There are two reasons you might want to use a crate, The first being that you want to use a good solid implementation that you know someone has spent more time doing and works better than almost any solution you could integrate. The second is you don't want to spend time implementing that.

Writing macros in rust is a pretty horrible experience but it's not difficult

Only the ones that make it easy. Language package managers are a mistake.

Just like c++ thought threads wasn't a std library concern and then later changed they minds, rust will also change tac I predict

The languages that have a poor standard library support have this issue and other languages encourage you to import tons of libraries to fix the problem.

This is why Javascript and Typescript suffer from this the most and has little to nothing to do with "popularity" and likely 9/10 of these npm packages import an external library.

Golang on the other-hand is just as popular and has a stronger standard library which people build against and it is encouraged to use its standard library rather than rolling your own or importing another package to solve the problem.

They aren't trivial, at least: https://docs.rs/arrayref/0.3.9/src/arrayref/lib.rs.html#202-...

Pulling in lots of dependencies creates this kind of risk regardless of the ecosystem. That being said in the JS/NPM world you tend to have a LOT more dependencies (especially indirect ones) than other languages. I saw someone do a cursory analysis and JS/Node projects tend to have 5x the number rust or ruby projects.

This is really a cultural problem not a technical one.

If it weren't a registry it would be ./configure scripts and makefiles. The issue is that sandboxing technology is kinda shit (especially x-plat) and languages don't build it in by default.

npm is mentioned 5x on this page.

Just wondering, whenever things go wrong with Rust - why do you all (Rust devs) point the finger at JavaScript?

It’s the weirdest form of projection. More than 1 person is doing it here. It’s like the second Rust hits a failure mode you immediately go “well JavaScript is worse!”

Like that has anything to do with your failure (even if it was true)

Edit: 7 times and counting

Cargo (and PyPI) is undeniably better than NPM, which is just shockingly bad for cultural reasons. Yet it's not safe, and it's subject to the same class of exploit, as we're seeing.

Indeed, the solution is to get away from the wild soup of author-managed dependencies and go with something with an audited collection of software that is maintained by separate human beings from the known-vulnerable hackers writing the software.

And indeed Go and .NET and Java all qualify. But the gold standard here is Debian and all its downstreams.

The idea that Rust has a small standard library is a weird meme. Rust has an enormous standard library. Look at any Rust release and you'll see dozens of new library APIs added, and consider that Rust has about nine releases a year, meaning that Rust adds over a hundred APIs per year, and has consistently for the past ten years. Rust frequently adds things that obviate popular crates, most recently the cfg_if crate was made redundant by the new cfg_select macro. And half of every dependency graph that people wrong their hands over are actually first-party external crates provided by either the Rust organization itself or by known contributors to the project. When people say that Rust has a small standard library, mostly they seem to just mean that it doesn't include a webserver.

I would like to know too, but the author's Github account seems to have been deleted, and the crates.io releases have been completely deleted too (not just yanked) so it seems impossible to view the file :/

Yeah I scanned the article and I couldn't find this either.

The author proposes to reinvent the wheel and depend on stale dependencies, which are EOL. Neither of that is an acceptable solution with LLM-based Agents being able to produce exploit(ExploitGym) chains in minutes from known bugs. The other issue is that Rust's forces the user to provide more information and APIs are usually kept generic for systems programmer, so standardizing things is not as straight-forward compared to Go where you can assume a memory-management, a virtual thread runtime and mostly ignore dynamic dispatching.

Honestly, Ginger Bill is plain wrong.

Just because you don't develop a package manager for your language, doesn't mean someone else won't. See NPM.

It usually takes some time for an updated dependency to actually get shipped to users in a release, by which time there's a good chance the attack has been noticed.

> Why do none of these hijacks embed runtime attacks? It seems like worming the build machines is the goal, rather than compromising downstream users.

Developer machines are quite juicy targets. They tend to have all sorts of credentials lying around, so it often isn't too difficult to escalate from that to compromising AWS/GCP/etc.

On top of that there's very little preventing a compromise. Developers are inherently expected to run untrusted code, and the usual Linux / MacOS laptop probably isn't even running any kind of anti-virus protection. Want to compromise the downstream app? Now you also need to pass Play Protect & friends.

> It seems like we should be building and testing everything in bubblewrap or some other sandbox going forward.

Yes, we really should. It is frankly a miracle that it has taken so long for fetch-time / install-time code execution to start blowing up in our faces. If we are spending so much effort on run-time isolation, why are we completely ignoring all those practices during development?

How do we know they don't? Who is going to read the source for all these micro packages?

You might assume we are able to detect all malicious behavior at runtime. But "stuxnet" and more recently, the xz compromise say otherwise. What if a not-so-popular crate deep in the dependency chain subtly introduced a LPE in it's code?

Mitigation for what?

Compromising the code that is then most likely run in a test instead of compromising a build script is just a very slight inconvenience for the attacker.

I'm not particularly fond of arbitrary build scripts either, but restricting them will not help the supply chain issue in a significant way.

Also there are several ways to control build.rs execution in the Cargo ecosystem, for example with cargo-deny.

As mentioned by others it’s just as easy for an attacker to modify a crate’s runtime code.

Who is funding this security audit? Are folks supposed to volunteer their free time? It's a difficult coordination problem. The best folks have come up is to delay adopting new releases by a few days and hope your dependency is popular enough that a security firm audits it for you in that timespan. If you have enough money I suppose you can start employing llms to audit things for yourself.

Mozilla, Google and a couple of others are publishing their audits through cargo vet. There are also additional audits done by individuals you can use through cargo crev. Overall the number of audited crates is in the thousands and you will find audits for most of the popular crates.

In the end it is your decision to use unaudited or refuse unaudited crates.