Hacker News

> 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, if i was at risk.

If anyone wants to create a revision to RFC 9110 :)

  HTTP/1.1 309 Security Advisory
  Location: https://acme/aaargh-another-advisory

I don't see the problem with boost? Isn't that a perfect example of your well supported, community embraced option? I certainly feel much safer pulling something in from boost via the official debian repos than I do pulling a random package with npm or cargo or etc.

Primarily I think the underlying concern has to do with the pathway for authoring code. When you have contributors whose submissions are gated with a rigid third party process and where that third party is the one responsible for curating the code (as opposed to the author also being the curator as well as the publisher) then you have the possibility to catch a lot of wrongdoing before it succeeds.

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

>There’s no reason why this can’t be replicated elsewhere. The key is to make the programming language reasonably robust with at least 80% of common non-UI dev needs built in and put the remaining 20% and UI bits into a small family of well-supported, community-embraced, preferably first party libraries.

The big reason is money & time. Maybe less so today if you are happy with an AI generated stdlib, but I don't think it's fair to compare Rust (built by Mozilla, who's primary product is an open source web browser) to Swift/AppKit (built by Apple, 4.6T marketcap at the time of writing).

When Go was released it had an amazing stdlib, but that was because Google was funding it.

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

> There’s no reason why this can’t be replicated elsewhere. The key is to make the programming language reasonably robust with at least 80% of common non-UI dev needs built in and put the remaining 20% and UI bits into a small family of well-supported, community-embraced, preferably first party libraries.

I wholeheartedly agree. Most standard libraries out there (when I say most I easily mean of 99% languages that I know) have pitifully tiny implementations. They at most provide for string parsing, io, a bare networking layer (that's at best a wrapper around the POSIX syscalls), threading and that's it. If you want to do anything more complex, you either have to roll it yourself or use an assortment of the "blessed libs" for any given language, that may or may not work properly, and may or may not even work well with each other. I got pissed off by this at some point so I decided to go ahead and roll my own standard lib that would actually have everything I need to.. actually develop apps. Now I know most people probably aren't going to be using it (mainly because its functional API isn't what most C++ devs want) but for me it's actually been brilliant.

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.

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.

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

>I think we should be taking a more “batteries included” approach

https://www.youtube.com/watch?v=GZOuz-SG7-g

Funny how you skipped "I should build my own batteries" and when straight to "increasing and centralizing the duties of your main gratis 'vendor'".

with LLMs it's becoming more common to just vibe up anything you need that might be missing. even if there is an available package you can pull in. the most secure option as well

Sandboxing is a mitigation but a very limited one. The library itself can contain a malicious payload -- rust code most often ends up as native code executed on the host.

I think we may need to enter a world where there are fewer, heavily audited, libraries and dependency depth is limited. Allowing unvetted dependencies to be installed by default is not a good way forward. App stores have a similar problem and I think a lot of lessons have been learned there that can be applied.

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.

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.

I'd like to see a "no-build" option to blocks depending on crates using build.rs

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?

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

I think it would be a good start if crates at least had to opt in to a build script, and adding one later would require permission from crates that depends on it.

The vast majority of crates don't need build scripts, so it is vaguely feasible to audit the list of crates you use that might need them.

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

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

How many times do we need to learn that sandboxing won't magically save us.

Eh, just because the likes of Anthropic are only threatening you with their latest model, it doesn't mean older models can't do exploits...

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.

Yep. Sorry for the spam, but look at this, compiling "yazi" from source (ie a relatively simple TUI file manager) 676 dependencies:

  Downloaded by_address v1.2.1
  Downloaded block-buffer v0.12.1
  Downloaded block-padding v0.4.2
  Downloaded adler2 v2.0.1
  Downloaded color_quant v1.1.0
  Downloaded blowfish v0.10.0
  Downloaded byteorder v1.5.0
  Downloaded bytemuck_derive v1.12.0
  Downloaded futures-sink v0.3.34
  Downloaded bs58 v0.5.1
  Downloaded critical-section v1.2.0
  Downloaded fnv v1.0.7
  Downloaded bytemuck v1.25.2
  Downloaded form_urlencoded v1.2.2
  Downloaded futures-macro v0.3.34
  Downloaded futures-io v0.3.34
  Downloaded blake2 v0.11.0-rc.6
  Downloaded find-msvc-tools v0.1.11
  Downloaded funty v2.0.0
  Downloaded fdlimit v0.3.0
  Downloaded ff v0.14.0
  Downloaded foldhash v0.2.0
  Downloaded bon v3.9.3
  Downloaded fdeflate v0.3.7
  Downloaded darling_core v0.23.0
  Downloaded bon-macros v3.9.3

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

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

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

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

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.

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

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

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

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?

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.

It's a pity that progress has been so slow.

https://github.com/rust-lang/cargo/issues/17009

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

just to clarify, by "horrible practice" you mean macros?

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.

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

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

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 share the dislike for arbitrary build scripts 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 as well, for example with cargo-deny.

The standard library is not versioned, so any API*/behaviour there must be maintained forever. When you put it in a separate crate, you can make better interfaces or be displaced by a better crate, while old code still compiles against the version it was written for. So even code effectively maintained within rust teams (hashbrown, rand, regex) may be in separate crates, std is specifically for OS abstraction and a shared type vocabulary.

That doesn't mean you jump to importing nonsense or trivial dependencies. The top hundred are efficient, well-designed crates of the quality you'd expect in a large std like Go or Swift, sometimes even higher as people can write better implementations that they otherwise wouldn't (or wouldn't be used over std). And those languages make breaking changes! C++ is mostly stable, so it's full of junk like <regex> or just unordered_map. Rust managed to wholesale reimplement HashMap 6 months after SwissTable released, like it is also easier to express this level of encapsulation, but that's part of countless design/interface decisions made deliberately to not constrain forwards compatibility, including a smaller std.

However, that's no excuse to have a worse developer experience in this area. We need better tools to vet and communicate the quality of a crate and its supply-chain, like community-curated or even additional org-maintained crates, and maybe a handful delivered precompiled in the default rustup distribution which can change over time. I don't think they need to be added to std itself though

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.

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.

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.

It's funny how left-pad was always brought up as a JS supply chain vuln when that wasn't even malware

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.

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.

It's not very surprising as the node attacks were very effective at gathering credentials.

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.