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

221–230 of 529 posts

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

#221

Post by Ygg2 »

leecommamichael wrote: post #171
Ygg2 wrote: post #169

Earlier quoted context omitted.

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.

Sure. Maybe threshold is bit higher than moderately. But unless your language tries to sabotage itself by making code artifacts uncomposable (a la C/C++ where best way to compose libraries is through shell commands) some package manager will be inevitable.

Batteries also don't help if dependencies don't replace them. Arrayref functionality has been part of Rust std lib for a while now.

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

#222

Post by QuadmasterXLII »

bryanlarsen wrote: post #218
QuadmasterXLII wrote: post #178

Earlier quoted context omitted.

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.

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.

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

#223

Post by echelon »

nemothekid wrote: post #220
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…

> There’s no reason why this can’t be replicated elsewhere. The key is to make the programming language reasonably robust with at least 80% of common non-UI dev needs built in and put the remaining 20% and UI bits into a small family of well-supported, community-embraced, preferably first party libraries. The big reason is money & time. Maybe less so today if you are happy with an AI generated stdlib, but I don't thi…

Python is batteries included, but all the batteries have corroded.

Look at C++'s long in the tooth STL.

You don't want to marry a language to fast aging libraries you have to support for eternity. Better libraries always naturally emerge.

Rust's decision here is fine.

The only thing I'd like to see is the ability to programmatically limit transitive dependency count or depth in Cargo. I'd also like crates to specify whether they limit their own deps and whether they have panick-y behavior or not.

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

#225

Post by burnt-resistor »

Aeolos wrote: post #107
burnt-resistor wrote: post #91

Earlier quoted context omitted.

Never going to work. Crates must be audited for behavior before use.

cargo add + rust-analyzer instantly executes build.rs before you have a chance to audit the code. Cargo, please PLEASE give me a way to disable third-party build.rs and whitelist the ones I need. And please loudly mark any update that adds a build.rs where there was none before.

Safe-ish recommendation: Only add well-known, trusted crates. Failing that, treat unknown crates as malware or containing malware dependencies until proven otherwise. Test untested tools/crates in a VM/dev container to be sure they work properly before trust them. Use Mark I eyeball and Mark III brain too. :)

Audit and limit crates (cargo-deny &| cargo-crev, && --offline) until tools exist to audit build.rs safety semi-automatically ($$ safeguard.sh maybe).

The root problem is two parts:

1. crates.io doesn't do mandatory curation. Lack of curation is fail. It's time-consuming and costly for reviewers without a doubt, but so is letting an ecosystem gain maximum entropy (go to shit) by Tragedy of the Commons depending entirely on the honor system. Name squatting, low-quality, unmaintained, typosquatting, and malware are the consequences of too much self-service / semi-self-service freedom.

2. Many, many cargo subcommands are over-eager to run build.rs because it assumes trusted crates:

In an untrusted/uncurated crates world and a build.rs exists or exists in a selected dependency, it shouldn't run at cargo-add time (unless it must). If it exists, on first run, it should be presented to the user in a viewer for manual review unless a magic CLI flag/env var is specified to accept it.

These 2 factors combined appear to create a Swiss cheese holes failure mode for running arbitrary crate `cargo add`. I have confidence a suitable add-in workflow &| standard command &| repository workflow will be adjusted to reduce the attack surface of the ecosystem.

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

#226

Post by killme2008 »

killme2008 wrote: post #224

We really need Cargo RFC #3923 https://github.com/rust-lang/rfcs/pull/3923 It would allow projects to avoid newly published dependency versions until a configurable waiting period has elapsed. npm has had a similar min-release-age feature for years.

It's a pity that progress has been so slow.

https://github.com/rust-lang/cargo/issues/17009

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

#227

Post by speedstyle »

abbadadda wrote: post #68

Are there any plans to more seriously develop the standard library in Rust? Or is the plan to remain in this status quo where users of Rust import nonsense and the dependency tree explodes (or users are forced to invent their own wheel?). Are there any comparisons between the state of the stdlib in C++ vs. Rust? I’d think that would serve as an excellent jumping off point to start chipping away.

The standard library is not versioned, so any API*/behaviour there must be maintained forever. When you put it in a separate crate, you can make better interfaces or be displaced by a better crate, while old code still compiles against the version it was written for. So even code effectively maintained within rust teams (hashbrown, rand, regex) may be in separate crates, std is specifically for OS abstraction and a shared type vocabulary.

That doesn't mean you jump to importing nonsense or trivial dependencies. The top hundred are efficient, well-designed crates of the quality you'd expect in a large std like Go or Swift, sometimes even higher as people can write better implementations that they otherwise wouldn't (or wouldn't be used over std). And those languages make breaking changes! C++ is mostly stable, so it's full of junk like or just unordered_map. Rust managed to wholesale reimplement HashMap 6 months after SwissTable released, like it is also easier to express this level of encapsulation, but that's part of countless design/interface decisions made deliberately to not constrain forwards compatibility, including a smaller std.

However, that's no excuse to have a worse developer experience in this area. We need better tools to vet and communicate the quality of a crate and its supply-chain, like community-curated or even additional org-maintained crates, and maybe a handful delivered precompiled in the default rustup distribution which can change over time. I don't think they need to be added to std itself though

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

#228

Post by cosmic_cheese »

nemothekid wrote: post #220
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…

> There’s no reason why this can’t be replicated elsewhere. The key is to make the programming language reasonably robust with at least 80% of common non-UI dev needs built in and put the remaining 20% and UI bits into a small family of well-supported, community-embraced, preferably first party libraries. The big reason is money & time. Maybe less so today if you are happy with an AI generated stdlib, but I don't thi…

There's probably to truth to this, but I would weight the design intention behind the language just as or more heavily than available resources.

Swift was intended from the start to not only replace Objective-C and all of its use cases, but also take on new use cases and bring a number of features from other languages that were newer and had different dominant paradigms.

Certainly having a juggernaut like Apple behind it has been instrumental in its success in achieving those goals. That said, a community-lead project with similar aims could probably achieve those aims as well, given enough time.

I think it's just rare for enthusiast-led projects to set out to do such things. My theory on why things tend to go that way is that the types of people to start programming language projects tend to heavily lean nuts-and-bolts and theory with a purist/idealist sort of mentality that's more concerned ideological purity than practical usability.

So to sum this all up, a community-run practical, multi-purpose, batteries-included language likely needs to at least partially designed and helmed by product engineer types so it doesn't end up anemic and stuck in an ideological rut.

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

#229

Post by burnt-resistor »

mike_hearn wrote: post #212
burnt-resistor wrote: post #88

Earlier quoted context omitted.

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

Why not object capability languages: https://blog.plan99.net/why-not-capability-languages-a8e6cbd...

No. Object-oriented brings things many languages cannot use. Also, that was a tl;dr fluff blog with barely any examples.

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

#230

Post by bhickey »

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

I'd like to see a "no-build" option to blocks depending on crates using build.rs
Post reply on HN