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

431–440 of 529 posts

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

#431

Post by piker »

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…

Maybe that’s a good place to make the cut. One Rust crate for game dev, one for data science, etc. Then their deps are pinned and monitored by the crate maintainers.

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

#432

Post by FacelessJim »

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 really like the approach Julia is taking. The std libs are their own packages with their own versions. You can then build your own “standard library” by compiling a sysimage that freezes the versions (you can add third party packages as well).

Practically speaking the standard library is just meant as “what’s included in the default sysimage”.

This allows to have different standard libs for different use cases. Think of Linux distributions in a sense. There are already a couple of alternative “stdlibs” out there for different focuses.

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

#433

Post by Klonoar »

robwayne wrote: post #355
jiggawatts wrote: post #331

Earlier quoted context omitted.

'bs58' jumped out at me as a random looking package name. It implements the base58 encoding, which is used primarily by... Bitcoin. I'd love to see the explanation of why "a TUI file manager" needs a crate closely associated with crypto coins and not much else. It is precisely this kind of thing that makes Rust a no-go for most enterprises. "I just want a CLI tool." "Congratulations, your servers are mining crypto!"…

It doesn't actually use it, this is just referencing it in the dependency graph (Cargo.lock). bs58 is an optional (feature-gated) transitive dependency of another crate, which is never referenced at all in the top-level crate. The build.rs doesn't run or anything. I believe there's (several) open issues about changing this behavior of the lock file, but I have moved on from Rust so don't know the status of things. Th…

The lockfile confusion/bug is indeed a thing, but OP is noting that b58 was downloaded, which makes me think it's actually used.

I ran in to the lockfile bug myself a day ago and noticed that dependency-feature-flagged-crates show up in Cargo.lock, but their crates aren't downloaded.

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

#435

Post by barnabee »

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…

I wrote this on another thread recently, but my line for exclusion from standard library is a library that’s any one of:

- not obviously/generally useful (i.e. useless or too specific/should be a program not a library)

- obviously trivial (code it yourself when you need it/compose from other primitives)

- already available (open source) elsewhere by a credible team that supports and maintains it

Anything else… put it in the stdlib

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

#436

Post by acje »

hbcdbff wrote: post #411
acje wrote: post #313

Earlier quoted context omitted.

I have generated a report based on my own exposure to this attack today. The report was updated as the attack unfolded; https://acje.github.io/systems/arrayref_incident_record/

Slop

It is ok that you feel this way. As explicitly stated the report is _generated_ and id does require a different mindset to read AI generated reports. It contains quite a bit of information about attacker behavior and details of the timeline. It also linkes to a story that is now largely human narrated and I´ll keep improving on that as I find time. Having to juggle three separate issues yesterday did not leave much time for manual writeups.

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

#437

Post by imtringued »

kelnos wrote: post #405
Pannoniae wrote: post #302

Earlier quoted context omitted.

>Most mainstream languages guarantee stability, certainly Rust. That's their mistake, right there... When you're upgrading software, you presumably want a better version. You can't have something better without changing it. It's a logical contradiction. >It doesn't matter if the code is in std or a crate. It very much does because you don't need 95% of the random stuff in the crates. Even for something like rand, you…

> That's their mistake, right there... No it's not. It's exactly what I want, at least. > When you're upgrading software, you presumably want a better version. Sure... > You can't have something better without changing it. It's a logical contradiction. No, that makes no sense. When I upgrade the rust compiler, I might want it to compile programs faster. I might want its borrow checker to be smarter so that it accepts…

Yeah it's pretty wild to demand things to be added to the standard library and then tell you that breaking backwards compatibility is fine. The first demand caused the need for the second. Meanwhile for non std libraries you can go ahead and do whatever you want.

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

#438

Post by jeroenhd »

account42 wrote: post #170
superxpro12 wrote: post #39

Earlier quoted context omitted.

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'll take all that over downloading and immediately executing random unreviewed code any day.

All of those can (and some do) wget source code from the internet and run it if you kick off their build pipeline. People just tend to use these tools differently.

Nothing is preventing anyone from distributing Rust crates as standard system packages, like some distros do with Python.

I think Debian is actually shipping rust libs in their repositories: https://wiki.debian.org/Rust Now Rust developers can also enjoy having to deal with popular packages that are years out of date/missing from popular repositories/getting deleted.

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

#439

Post by barnabee »

mightyham wrote: post #191
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…

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…

Serde is not even part of the standard library. There’s no HTTP client (let alone server), logging, decent date/time…

That’s not what I call well featured.

Most programs should need close to zero dependencies.

Of course they’re free to do what they want, and there’s the question of maintenance overhead[0], but while https://blessed.rs/ needs to exist, Rust’s standard library is deficient in my eyes.

[0] One idea would be to treat a language more like an Linux distro and have library maintainers like package maintainers but a unified quality, audit, and release process

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

#440

Post by imtringued »

pjmlp wrote: post #262
pie_flavor wrote: post #242

Earlier quoted context omitted.

Platform support is a non-issue for every library being discussed. This is an array construction macro, it has nothing to do with what operating system you're running on.

Just because some trees have a specific trait, it doesn't mean the whole forest is the same.

Your argument only works for no_std crates, but the std exists and allows the vast majority of crates to be cross platform out of the box.
Post reply on HN