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

451–460 of 529 posts

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

#451

Post by VorpalWay »

Orphis wrote: post #446
VorpalWay wrote: post #342

Earlier quoted context omitted.

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

C++ ended up in that situation because they don't want to break backwards compatibility (ABI, API) or change contracts, except in some rare cases, even on major releases. Quite often, it is a vendor issue to break the ABI and fix issues, and some have refused to do that. It's a self-inflicted issue that most other languages with "batteries included" don't have since they will document breakage and upgrade paths when…

Rust has committed to a stable API (but the ABI is explicitly unstable). Which makes sense for a systems language. It isn't (and doesn't want to be) a kitchen sink language.

But even something like Python has lots of cruft in its standard library. And they are willing to make breaking changes. Nobody should use urllib.request for example, requests is a far better HTTP client library. To the point where the stdlib docs tell you so.

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

#452

Post by VorpalWay »

pjmlp wrote: post #413
VorpalWay wrote: post #353

Earlier quoted context omitted.

Which is how you get the mess that is the standard library of C++. Where regex is an unusably slow joke and everyone uses third party libraries for that instead. And tons of parts of the standard library (and language) being cordoned off as "legacy, don't use for new development". Of course figuring out what you shouldn't use in C++ can be hard too. It isn't well documented (or universally agreed upon), and it takes…

Regex drama is overblown, it is quite usable for most business purposes. Sure, it would be great if the volunteers that contribute to C++ compilers, would improve regex instead of adding the gazillion of features that each ISO C++ standard requires, mostly on their free time, because devs can't be bother to pay for compilers. Additionally the companies that actually sponsor those compilers also have bigger priorities…

Regex issues aren't at all overblown, at least in the fields I have worked in or in fields of people I have talked to.

As for async in Rust, I wrote in another comment that yes that is an issue. What we need is std to define traits that all the different runtimes can implement. Because there are absolutely reasons to use alternative runtimes, depending on what you do. I mostly use embassy (embedded microcontroller development) for example. And if you want thread-per-core with io-uring you want glommio or monio. Smol is simple and compact.

I could also see uses for async in desktop GUI or gamedev (but to my knowledge there isn't any runtime suitable for those domains yet).

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

#453

Post by klabb3 »

weinzierl wrote: post #84
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 just build.rs would only be be a minor inconvenience for the attacker, nothing more. The attacker can always as easily compromise the binary you build and as soon as you run it (e.g. in a test) you are owned. It would be a big pain for many that are in the unfortunate position to really need build scripts, though.

100% agree. Wow I can’t believe how many think sandbox builds is an actually good idea, on a per language basis too. There are completely standard QoL issues in cargo that have been open for years and nobody is working on. Maintaining a sandbox for idk 3 operating systems minimum that have virtually no sandboxing support? For extremely diverse workloads that typically invoke commands? I mean.. good luck.

There are still elephants (or rather mammoths) in the room for supply chain security, such as having 1500 nested deps for a standard project. It’s like we never woke up from the nightmare of leftpad.

If your project had code from 100s of individuals, new versions can be pushed instantly, and nobody wants to review the code, then you have a time bomb. And also other problems.

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

#454

Post by burnt-resistor »

mike_hearn wrote: post #326
burnt-resistor wrote: post #229

Earlier quoted context omitted.

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

All languages in mainstream use are imperative and at least somewhat object oriented, other than SQL. But many of those don't have what it takes to implement capabilities (too flexible/dynamic).

No, this is false and you're using weasel words and creating a strawman.

I said add functions or capabilities to make it happen.

You don't read.

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

#455

Post by VorpalWay »

pjmlp wrote: post #415
VorpalWay wrote: post #354

Earlier quoted context omitted.

Don't forget C++ where large parts of the standard library are unusable (regex is slow and unfixable) or soft deprecated (dont use iostreams for formatting, use std::format, etc). No, I prefer what rust is doing. It suits a system programming language. Which is what Rust is.

Regex does the job for most business software, iostreams is alright, using them since 1993, std::format is cool provided one has control over their compiler version,...

Regex is absolutely not suitable for most use cases that I have come across. Iostreams formatting is awful, especially if you care about internationalization (which is very common).

Not sure what the issue with std::format would be here, you would have to elaborate. Obviously you need to specify a minimum version to have support for it at all.

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

#456

Post by thatspartan »

lovehashbrowns wrote: post #394
cloudfudge wrote: post #347

Earlier quoted context omitted.

I think one thing that has made Go have better dependency hygiene is not merely having "batteries included" in the standard lib, but the early focus on having production-ready implementations of a lot of stuff in the standard lib, as opposed to minimum viable implementations. I used to get a long way with one or two dependencies that would barely fan out at all. It's been a while since I worked on a Go project, so I'…

I think having production-grade implementations makes a huge difference also. Go’s net/http in the std lib feels like a good example of that, though I’m fairly new to go still. But it seems net/http still gets pretty big updates despite something like Chi being available as an external lib. Odin is doing this as well, even including raylib in the std lib. Odin is even more primed to keep you on the std lib as it does…

So I went to have a look at Odin and was mind blown at the lispiness in the hellope example. A list of operators defined as "program"; that are applied to the accumulator then printed. It's a striking first impression for me and I want to see what the Odin people have cooked up.

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

#457

Post by pseudony »

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…

You can never please everyone , and some stdlibs can age like milk (see ocaml).

Having libraries allow the community to explore rather than saddling it with a bad default. See the number of http server frameworks etc.

The real solution here is not for the stdlib to become a black hole, swallowing up every half-way popular library a but rather for “rustaceans” to adopt a more security-conscious approach to writing programs- C programs typically have few and well-chosen dependencies. Some languages, like Odin, completely eschew package managers because they see the very real issues stemming from writing a program with scores or hundreds of dependencies.

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

#458

Post by ModernMech »

CrimsonCape wrote: post #298
segphault wrote: post #195

Earlier quoted context omitted.

This is spot on. I am extremely uncomfortable with the large number of transitive dependencies that end up in pretty much any non-trivial rust application. No amount of memory safety will save us if a tiny, ubiquitous library that nobody scrutinizes because it’s nested eight layers down the dependency graph gets compromised. I think Go apps tend to have better dependency hygiene because the language has a better stan…

I learned programming from C# which has an excellent standard library. Just recently started using Go which seems to have a good standard library. Been using python for years, can't say I ever had a complaint about the standard library. Rust meanwhile seems to be following some "no standard library" philosophy. I feel like there's an opportunity out there to become like an amoeba: fund and build a third party Rust st…

> Rust meanwhile seems to be following some "no standard library" philosophy.

As an embedded dev, I personally find it very useful to compile Rust programs without a standard library. I would not use C# or Python for an embedded project for the reasons you probably prefer them for your projects.

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

#459

Post by badsectoracula »

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…

> Nobody can agree on what those common things are in a general purpose langusge though.

Well, then take the Lazarus / Free Pascal's approach and just put everything :-P. It isn't like code takes THAT much space.

If you install Lazarus you get a ton of stuff out of the box, aside from the crossplatform WYSIWYG RAD IDE and desktop application framework you also get 2D graphics libraries (with a bunch of image i/o), networking libraries, (de)compression libraries, a webapp framework, database clients, parsers for json, xml, markdown, javascript and a bunch of other stuff (even a parser for the language itself), a TUI framework, bindings for a bunch of external libraries and other stuff.

And all that stuff (or at least most of it) work on all the platforms the compiler supports. Yes, using FPC you can probably (didn't try) make a pretty markdown viewer with inline JPG and PNG display support that runs on Windows 3.1 :-P.

Unfortunately some people are trying to break this and introduce online package management, but so far at least FPC and Lazarus comes out of the box with not just batteries included but an entire carton of batteries just in case :-P.

Post reply on HN