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

371–380 of 529 posts

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

#371

Post by bryanlarsen »

QuadmasterXLII wrote: post #222
bryanlarsen wrote: post #218

Earlier quoted context omitted.

I expected somebody to pull out an example "disproving" my point. It wouldn't be hard. I can point out rust projects that have a ton of external dependencies, and then point at similar projects with very few. But a Python example doesn't really count, in my mind -- Python is pre-GitHub so tends to have small numbers of large external dependencies, like C++ and other older languages.

If a python example doesn't count, why were your two example languages python and go? But yeah, small number of large dependencies is the way to go.

Replying to the sentence "The dependency tree of comparable Go and Rust projects seem comparable, IMO." with a Python example seems pretty odd.

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

#373

Post by ksbd-pls-finish »

VorpalWay wrote: post #342
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…

> 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. Nobody can agree on what those common things are in a general purpose langusge though. It works for something like Go, because it is largely used for servers an…

Well I use python daily for the past 10 years and I never did data science. Data science? Everyone knows python is the language of cyber security.

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

#375

Post by Ygg2 »

aselimov3 wrote: post #254
Ygg2 wrote: post #124

Earlier quoted context omitted.

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.

Sure. And people shouldn't steal people's credentials and publish malicious artifacts, yet here we are.

Just because you expect people to behave like X doesn't mean they will. In this case people will automate packaging of artifacts.

NPM was a third party manager (it's not part of EcmaScript nor was it part of Node.js at start) and so is Maven. Reputation matters more than origin.

Those who do not know history are doomed to rediscover it.

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

#377

Post by hbbio »

rfgplk wrote: post #269
hbbio wrote: post #79

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

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

You can't imagine how much your example calls home!

https://github.com/hbbio/rc

In my opinion, library authors should really minimize the amount of dependencies they have. Back to TypeScript, we are also the authors of https://github.com/okcontract/cells and we made a point of almost not having dependencies or even devDependencies.

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

#378

Post by woodruffw »

rfgplk wrote: post #269
hbbio wrote: post #79

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

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

I don’t know anything about this particular tool. But I’ll note that comparing package counts often doesn’t make sense between ecosystems, since some ecosystems (like Rust) lean heavily towards workspace patterns where several “physical” packages make up one “logical” unit.

(Rust even enforces for proc macros, which is why so many of the crates in your example end with “derive” or “macros.”)

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

#379

Post by cosmic_cheese »

josephg wrote: post #344
cosmic_cheese wrote: post #247

Earlier quoted context omitted.

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…

The counterpoint is that whatever std invents is probably not going to be as good as what moviated people in the community make. The rand crate is my favorite example of this. They have a whole bunch of different rngs. All rated by quality and performance. Some are csrngs and some aren’t. It’s a delight. “Batteries included” languages don’t come close. Then there’s serde - which uses a clever technique with traits to…

> Maybe std should pick up the best crates from the community and bring them in house? This might be a good idea. But also maybe not. Since serde came out, several other crates have found ways to crush its performance numbers. Often by 2-5x if memory serves. What a relief we didn’t immortalise the slow version of serde, right?

I think periodically rolling in the best crates is the way.

Don't immortalize anything, though. Always reserve the freedom to swap out integrated crates when something better rolls around. Negative impact can be reduced by limiting these kinds of changes to major new versions.

Another option is to swap internals while keeping the same public API. Apple has done this several times with Swift, resulting in massive speed improvements in things like string handling and JSON decoding without breaking anybody's code.

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

#380

Post by stubish »

sunshowers wrote: post #336
segphault wrote: post #195

Earlier quoted context omitted.

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…

Every Rust crate is heavily scrutinized these days using LLMs (which also caught this issue). The days when no one looked at dependencies are gone.

At upload time? Or by every client at download time? Or just adhoc by random users?

This does sound like an excellent way of improving automated package checks, even if it does result in some false positives and false negatives. For all sorts of packages, not just code dependencies.

Post reply on HN