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

241–250 of 527 posts

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

#241

Post by cpill »

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…

with LLMs it's becoming more common to just vibe up anything you need that might be missing. even if there is an available package you can pull in. the most secure option as well

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

#242

Post by pie_flavor »

pjmlp wrote: post #240
0cf8612b2e1e wrote: post #160

Earlier quoted context omitted.

On the other hand, there are some bad Go standard libraries that are frozen in time.

Yeah, but I will take a not great library that works everywhere the compiler does, than be at the whims of which platforms are supported by 3rd party libraries. I can use most of the clunky Python, Java, .NET and if it must be, Go, standard libraries, than hunting down for dependencies with platform tier support and such.

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.

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

#243

Post by im3w1l »

echelon wrote: post #223
nemothekid wrote: post #220

Earlier quoted context omitted.

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

Can we pick and choose the good without the bad? If we agree stability is a net-negative we could just say there will be a list of blessed trustworthy libraries with extra scrutiny and bureaucracy (make no mistake this is completely necessary to what people are asking for) to make sure they don't go rogue. But without a guarantee they will stick around and get updates forever.

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

#244

Post by pie_flavor »

mike_hearn wrote: post #213
swiftcoder wrote: post #93

Earlier quoted context omitted.

build.rs by design can run absolutely anything. There tons of build.rs scripts that invoke a whole-ass C compiler toolchain to build and link C dependencies... It isn't so much a question of sandboxing build.rs, as fundamentally changing the way that foreign dependencies are integrated into the rust toolchain (i.e. moving from a rust-centric system like Cargo to something more general like buck2)

Worth noting that the JVM ecosystem doesn't have this issue because there is no notion of installing dependencies, and the package managers are just downloaders with nothing else. No build.rs equivalent. To solve the problem of native/C dependencies, they just bundle pre-compiled libraries as data files. Rust could do the same thing.

ABI stability is significantly different in a VM language to a native language, and reified generics necessarily require source compilation. Binary-only development for Rust would be exactly as 'sort of not really' as C++, for exactly the same reasons. (There is also no notion of 'installing' dependencies in Rust, and build-time code being malicious isn't much worse than runtime code being malicious.)

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

#245

Post by pie_flavor »

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.

You can disable rust-analyzer running build scripts.

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

#246

Post by sempron64 »

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

Sandboxing is a mitigation but a very limited one. The library itself can contain a malicious payload -- rust code most often ends up as native code executed on the host.

I think we may need to enter a world where there are fewer, heavily audited, libraries and dependency depth is limited. Allowing unvetted dependencies to be installed by default is not a good way forward. App stores have a similar problem and I think a lot of lessons have been learned there that can be applied.

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

#247

Post by cosmic_cheese »

TZubiri wrote: post #235
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 https://www.youtube.com/watch?v=GZOuz-SG7-g Funny how you skipped "I should build my own batteries" and when straight to "increasing and centralizing the duties of your main gratis 'vendor'".

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

I'm happy to contribute to a larger effort but anything I can build on my own is going to be a thin, flimsy happy meal toy compared to something with the backing of a company or well organized FOSS project.

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

#249

Post by pjmlp »

grommz wrote: post #165
kibwen wrote: post #112

Earlier quoted context omitted.

First we need capability-based OSes, like we should have had decades ago if worse-is-better hadn't stuck us with Unix. I don't need to care whether or not a program was written in a capability-aware language if the OS fundamentally takes care of that for me.

HarmonyOS is a capability based OS. I don't know why anyone in China is still using Rust. The biggest social engineering hack was for the Rust team to convince developers that it is a safe language.

Actually HarmonyOS NEXT is getting its language as well, Cangjie.

https://cangjie-lang.cn/en

https://cangjie-lang.cn/en/docs?url=%2F1.0.0%2Fuser_manual%2...

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

#250

Post by pjmlp »

neutronicus wrote: post #119
wasmperson wrote: post #27

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…

The "npm-ness" of Cargo (centralized and standardized dependency management used at every opportunity) is generally pitched as one of the primary developer experience advantages over C++.

For those missing the npm like experience in C, they can use apt, yum, dnf, winget, nuget, conan, vcpkg.
Post reply on HN