Malicious Rust crate Arrayref runs a build-time payload • Hacker News Board

Re: Malicious Rust crate Arrayref runs a build-time payload

#251

Post by burnt-resistor » Thu, Aug 20, 2026, 6:43 PM UTC

kibwen wrote: post #112

burnt-resistor wrote: post #88

Earlier quoted context omitted.

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

First we need capability-based OSes, like we should have had decades ago if worse-is-better hadn't stuck us with Unix. I don't need to care whether or not a program was written in a capability-aware language if the OS fundamentally takes care of that for me.

1. seL4 exists. I haven't seen much more formal and rigorous than it. Efforts have ported the Linux kernel and RTOS-things to it.

2. Add syscall(s) to POSIX, which encourages *nix adoption, with an API like the following:

- Drop capabilities for thread/process except allow list.

- Test if current thread/process has all listed capabilities.

- List should be able to represent capabilities and their attributes, much like a single unveil() OpenBSD call, maybe as an array of/pointer to struct.

- (Program crashes if syscall capability is missing.)

Re: Malicious Rust crate Arrayref runs a build-time payload

#252

Post by aselimov3 » Thu, Aug 20, 2026, 6:43 PM UTC

jooops1 wrote: post #152

aselimov3 wrote: post #90

Rust finally got hit... This was motivating me to swap away from Rust towards because of the huge number of dependencies. It seemed inevitable. Ginger bill was right, https://www.gingerbill.org/article/2025/09/08/package-manage...

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 comp…

I don't think anyone is saying that you should depend on stale dependencies. You should not hand off your responsiblity to untrustworthy package managements services though. Evidence of the failure of automated package management is the near constant shai-hulud attacks as well as the originating post here.

The fact is that your dependencies are your responsibility. You should be staying up to date on what you depend on and their vulnerabilities. Most vulnerabilities affect specific code paths which may not be present in your code base and do not require mitigation. These are decisions you can make by understanding what your dependencies are instead of offloading to automated package management systems.

NPM has been the posterchild of these types of issues but the dependency stack I saw everytime I compiled even simple programs in Rust made me think Rust would be impacted next. Personally I think third party modules that are effectively universally used (axum, tokio, serde) should be integrated directly into the language.

Re: Malicious Rust crate Arrayref runs a build-time payload

#253

Post by 7373737373 » Thu, Aug 20, 2026, 6:43 PM UTC

sempron64 wrote: post #246

jakubadamw wrote: post #41

Cargo 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 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 thin…

That's why languages need sandboxing at runtime as well

Re: Malicious Rust crate Arrayref runs a build-time payload

#254

Post by aselimov3 » Thu, Aug 20, 2026, 6:44 PM UTC

Ygg2 wrote: post #124

aselimov3 wrote: post #90

Rust finally got hit... This was motivating me to swap away from Rust towards because of the huge number of dependencies. It seemed inevitable. Ginger bill was right, https://www.gingerbill.org/article/2025/09/08/package-manage...

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.

Well I think the main important argument here is you shouldn't use the package management. A third party package manager would be even more concerning to use imo. I generally try to stay away from the typescript world so unfamiliar with nuances of NPM.

Re: Malicious Rust crate Arrayref runs a build-time payload

#255

Post by derefr » Thu, Aug 20, 2026, 6:45 PM UTC

deathanatos wrote: post #184

cube00 wrote: post #114

GitHub 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…

> That wouldn't be desirable in the case of a compromised crate: you don't want a download occurring at all.

Sure you do; you just don’t want the crate to be made available to people trying to make use of the crate as regular downstream consumers. You still want the crate available for download for analysis. You especially want to be able to deterministically reproduce the vulnerable version of your software that you already built.

I would posit that most package ecosystems should treat “contains an exploit” as its own package state; mostly ignore them; but still be aware of their existence.

In other words, if there’s any other non-exploited option under your version constraints, the dep should resolve to the nearest non-exploited version, even if older. But if it’s the only version, or if you have pinned the exploited version, then the packager should see it, but normally refuse to interact with it—i.e. refuse to lock to it if it’s the only version; or refuse to fetch it if it’s the locked version.

I say “normally” because you should be able to bypass this with a flag / env-var to the packager that basically means “I’m building this for forensic analysis, not for running.”

Re: Malicious Rust crate Arrayref runs a build-time payload

#256

Post by __david__ » Thu, Aug 20, 2026, 6:47 PM UTC

segphault wrote: post #195

cosmic_cheese wrote: post #78

I 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…

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 stan…

I think Go ends up with fewer dependencies mostly because there is more friction in finding them. With rust (and npm) you just "cargo search xxx", then "cargo add xxx". Go makes you web search and poke around github looking for something. It's not onerous or anything, but just that extra step slows things down just a bit. C projects tend to have the least because it's even more annoying to add them and you have to create build commands that deal with slightly different distributions (and learn makefile+pkg-config or cmake, or autoconf).

Certainly having a larger stdlib helps Go projects keep their deps down, but I don't think it's the real reason.

Re: Malicious Rust crate Arrayref runs a build-time payload

#257

Post by 7373737373 » Thu, Aug 20, 2026, 6:48 PM UTC

throwaway894345 wrote: post #121

vaylian wrote: post #115

Earlier quoted context omitted.

> 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 don’t even understand what a capability based language is, but presumably closed source software wouldn’t apply here? Is it common for closed source software to give the source code to customers to build?

Closed source software could apply too, if the execution model supports it (e.g. WebAssembly). Just because the format is binary and "unreadable", its permissions (accessible functions) don't have to be

Re: Malicious Rust crate Arrayref runs a build-time payload

#258

Post by k_roy » Thu, Aug 20, 2026, 6:50 PM UTC

sempron64 wrote: post #246

jakubadamw wrote: post #41

Cargo 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 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 thin…

That world can’t exist unfortunately, because the minute someone wants a feature that isn’t in your core libraries, you just create a new library and we’re back to now.

Re: Malicious Rust crate Arrayref runs a build-time payload

#259

Post by einrealist » Thu, Aug 20, 2026, 6:53 PM UTC

cube00 wrote: post #114

GitHub 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:…

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

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

Re: Malicious Rust crate Arrayref runs a build-time payload

#260

Post by TZubiri » Thu, Aug 20, 2026, 6:53 PM UTC

cosmic_cheese wrote: post #247

TZubiri wrote: post #235

Earlier quoted context omitted.

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

I don't like the "bring your own" approach because unless one happens to be an absolute tour de force 10x engineer unstoppable god of a programmer (which most of us, myself included, are not), whatever you build is never going to be as well-rounded, fleshed out, and complete as something built by a larger organization, especially when it comes to UI libraries (which are monstrous projects if done right, e.g. meeting…

I agree that building your own is hard and something that can be done by exceptional engineers, but software is famously a winner-take-all industry, even if the optimal strategy for lower percentile programmers and median programmers to import generic modules, as long as building your own results in the best product (which it does, whether importing frontend or backend modules, if you hand code something, it's going to be the optimal strategy for building a winner product. Even programmers that are median or below average probably have an incentive to aim for being exceptional, because the best value of median and below average programmers is not building median or low value software, but having a shot at building exceptional software.

Also the challenge of building a generic module is much larger than building your own. A generic module needs to have flexibility for many different options and integrations, when you build your own you build just what you need and tightly integrate it with the product