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

121–130 of 529 posts

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

#121

Post by throwaway894345 »

vaylian wrote: post #115
tancop wrote: post #75

We need effect based languages now. It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles. If anyone from epic is reading this please give us a timeline for open sorucing the Verse compiler. In the mean time I think it's possible to hack Cargo and run all build scripts in a microVM. The blast radius will be limited to malicious code in the…

> It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles. It's not the only way. You can sandbox processes. I think sandboxing is the much more reasonable approach, because in the end of the day, there are still closed-source software products where you can't demand that the manufacturers use certain language safety features.

I don’t even understand what a capability based language is, but presumably closed source software wouldn’t apply here? Is it common for closed source software to give the source code to customers to build?

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

#122

Post by nelup20 »

superxpro12 wrote: post #39
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…

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

Conan, Meson, Ninja, Bazel, meta-build tool / dependency manager #231 etc. etc. And then you have to deal with all the modern C++ and STL footguns.

It never ends .·°՞(っ-ᯅ-ς)՞°·.

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

#123

Post by dematz »

Jumping off the title and ignoring contents of post, as is customary: look at this graph and guess which languages use each number of dependencies for their website: https://www.youtube.com/watch?v=E82ly38YEEQ&t=325s

I won't spoil the claim in the video about what the dependency number is correlated with, and I'm not even sure how true it is in general, but it's very interesting.

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

#124

Post by Ygg2 »

aselimov3 wrote: post #90

Rust finally got hit... This was motivating me to swap away from Rust towards because of the huge number of dependencies. It seemed inevitable. Ginger bill was right, https://www.gingerbill.org/article/2025/09/08/package-manage...

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.

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

#125

Post by bluGill »

throwaway894345 wrote: post #121
vaylian wrote: post #115

Earlier quoted context omitted.

> It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles. It's not the only way. You can sandbox processes. I think sandboxing is the much more reasonable approach, because in the end of the day, there are still closed-source software products where you can't demand that the manufacturers use certain language safety features.

I don’t even understand what a capability based language is, but presumably closed source software wouldn’t apply here? Is it common for closed source software to give the source code to customers to build?

> Is it common for closed source software to give the source code to customers to build?

Yes, somewhat common. I work in embedded, and where a supplier gives us the ability to build their code it is a lot easier for us to deal with the next time we need a new build from them.

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

#126

Post by abhisek »

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

This is exactly what PMG is designed for ie. install/build time process level sandboxing. It currently doesn't support cargo, but I believe the challenges are same.

Here is my learning building PMG:

Sandboxing is good when the workload is predictable, and the goal of sandbox is to guard against exploitation of vulnerabilities, like sandbox protecting chrome tabs (renderers). But unfortunately build scripts are not predictable, at least not in npm/pypi world and I have seen build scripts doing weirdest of the things which is no different from malware. When popular packages do weird things, build breaks and users end up turning off the sandbox. This is a perpetual problem to deal with while building sandbox (or any least privilege solution) to protect unbounded workloads.

https://github.com/safedep/pmg

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

#127

Post by jfklgkdkdnn »

pluralmonad wrote: post #98
abbadadda wrote: post #57

Earlier quoted context omitted.

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

I think it was to make the tongue-in-cheek nature of the comment more apparent.

That’s undeniable.

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

#129

Post by lyu07282 »

nicoburns wrote: post #60
bcjdjsndon wrote: post #14

Earlier quoted context omitted.

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

> This crate isn't one of them.

still caught in hours though, so just as a general rule: never install anything newer than 7 days old packages

cargo feature for this is still unstable infuriatingly:

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

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

#130

Post by llleeeoooh »

jfklgkdkdnn wrote: post #67
fidotron wrote: post #33

Doing software development outside of strict containerization, at the very least, looks increasingly prone to disaster. Yes, we can argue about the culture of package management (as some of us have with especially npm from day one), but it's done, and your colleagues or AI sidekicks cannot be trusted not to download whatever and try to build and run it. All you can do is limit the effective blast radius.

minimum-release-age

is there a way to set up without using the nightly build?
Post reply on HN