Live data from Hacker News

Malicious Rust crate Arrayref runs a build-time payload

safedep.io

51–60 of 529 posts

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

#52

Earlier quoted context omitted.

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

Rust is actively incorporating more functionality into the stdlib. The functionality of this crate has been in std since 2024. The ecosystem is just slow to update (not everything is maintained, etc).

[flagged]

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

#53
post #18

> arrayref is a small crate of four macros. Why do so many languages fall into this horrible practice?

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…

Go has a stronger standard library for certain use cases like basic CRUD web applications, but a lot of the Go standard library is also extremely low quality (flag, container, image, json, log, math, path, regexp, sync, time). Many of these aren't usable outside of toy use cases and have weird edge cases all over the place. Over time many will probably get new incompatible versions just like json. The container package in Go is the worst collection library in any mainstream programming language by a huge margin. It's actually astounding how bad it is.

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

#55

Earlier quoted context omitted.

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…

i'd like to welcome you to the hell that is c/c++ dependency management. Make? cmake? qmake? conf? autoconf? configure? autotools? submodules??? AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

I'd just select a tool, vendor the libraries I need to the codebase and call it a day. Did these for Eigen, liboption++, Catch2, Easylogging++ (now archived and not maintained anymore, sadly).

Build a simple makefile, and you're off to the races.

At least, for my cases, that is.

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

#56

Earlier quoted context omitted.

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…

[flagged]

Rust as a language is mostly alright in my opinion. The problems I have with it are similar to the problems I have with C++, and it makes up for them in other really compelling ways.

Where it loses me is Cargo and everything surrounding it. I'm essentially forced into an extreme where I just never use anything in the Rust ecosystem, or I have to deal with insane dependency graphs that have the density and microstate complexity of a neutron star.

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

#57

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.

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

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

#58

Earlier quoted context omitted.

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.

You’re right about attackers being able to change runtime code. pnpm does have some other features to prevent supply chain attacks, so there is still something to learn from other ecosystems. For example pnpm has a cooldown period for new dependencies and can prevent trust policy downgrades (eg new version published without build provenance where older versions did have it). See https://pnpm.io/supply-chain-security

> pnpm has a cooldown period for new dependencies

Cargo has `min-publish-age` in nightly, and it's currently heading towards stabilization: https://github.com/rust-lang/cargo/pull/17335

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

#59

Earlier quoted context omitted.

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…

i'd like to welcome you to the hell that is c/c++ dependency management. Make? cmake? qmake? conf? autoconf? configure? autotools? submodules??? AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

xmake, build2, whatever msvc and xcode insist upon…

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

#60

Earlier quoted context omitted.

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.

> Who is funding this security audit? Are folks supposed to volunteer their free time? Same people who keep the whole rust project going, a lot of those are volunteers aren't they? Not mad to think they could do the same for core packages at least

The core packages (things like rand and regex) are pretty closely audited in practice (albeit it might not catch a credential compromise).

This crate isn't one of them.

Post reply on HN