Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious Rust crate Arrayref runs a build-time payload

safedep.io

Post reply on HN
Print view View original

171–180 of 529 posts

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

#171

Post by leecommamichael »

Ygg2 wrote: post #169
leecommamichael wrote: post #86

Earlier quoted context omitted.

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

Spoiler alert! JavaScript has no language provided package manager. If Odin gets moderately successful someone will probably reinvent it.

NPM came along in 2010, Javascript was huge before that.

It was only when people wanted a common approach to shipping both in browser and "native" that this glitch happened. I believe a standard library and "batteries" would have abated it entirely or resulted in a slightly less-bad situation. I do think Cargo is a slightly less-bad situation in many ways, and that it can be done better.

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

#172

Post by hmry »

demibabs wrote: post #11

What does the malicious code actually do?

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 :/

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

#173

Post by jurgenburgen »

lobofta wrote: post #145
Panzerschrek wrote: post #76

Earlier quoted context omitted.

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.

So let each build script define its own level of sandboxing and then users can determine whether they are okay with that level or not, e.g. `cargo build --sandbox-level=...`

That’s not solving the problem, that’s avoiding it by making it the users fault if they make a mistake.

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

#174

Post by landr0id »

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

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

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

#175

Post by jmull »

tancop wrote: post #75

We need effect based languages now. 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. If anyone from epic is reading this please give us a timeline for open sorucing the Verse compiler. In the mean time I think it's possible to hack Cargo and run all build scripts in a microVM. The blast radius will be limited to malicious code in the…

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

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

#176

Post by rirze »

vatsachak wrote: post #15

All those folks telling me to update my dependencies, this is why I don't do it. It's not laziness, it's undeniable foresight.

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.

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

#178

Post by QuadmasterXLII »

bryanlarsen wrote: post #32
rvz wrote: post #18

Earlier quoted context omitted.

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…

I've never seen a non trivial Python or Go project without external dependencies. The dependency tree of comparable Go and Rust projects seem comparable, IMO.

Pytorch has 9 transitive dependencies for cpu-only execution, or 29 to bring in cuda.

candle, the most popular rust ml library I found in a cursory search, has 119 for cpu only, and 150 to bring in CUDA.

I guess it's taste whether that's comparable

this would have been a way more satisfying dunk if nvidia hadn't split the cuda functionality needed by pytorch into 19 (!) packages on pypi but such is life.

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

#179

Post by nicoburns »

rcxdude wrote: post #80
nicoburns wrote: post #49

Earlier quoted context omitted.

> 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. I think we might be able to crowdsource audits. At least in the Rust ecosystem I'm confident that this is feasible with the right tooling.

Cargo-crev already exists if you care to use it.

It does, but the UX is pretty lacking compared to the regular package workflow.

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

#180

Post by cube00 »

landr0id wrote: post #174
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:…

[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 GitHub issue was opened 8 hours ago. The cargo.io team also acknowledged it 8 hours ago. [2]

> [3] is no longer true.

Previously published versions shouldn't just disappear from the list. There's still nothing there to indicate a version was yanked.

[1]: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on...

[2]: https://rust-lang.zulipchat.com/#narrow/channel/318791-t-cra...

Post reply on HN