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

441–450 of 529 posts

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

#441

Post by account42 »

jeroenhd wrote: post #438
account42 wrote: post #170

Earlier quoted context omitted.

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

Of course they can be made to do anything but that's not what they are designed for and as a result they also build a culture that frowns upon doing that. Debian and other Linux distributions would have never had the policy do handle dependency resolution themselves if contemporary build systems automatically fetched everything automatically rather than being designed to use dependencies provided by the user.

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

#442

Post by speedstyle »

waterTanuki wrote: post #412

> append-only-vec > This is a pretty simple type, which is a vector that you can push into, but cannot modify the elements of. The data structure never moves an element once allocated, so you can push to the vec even while holding references to elements that have already been pushed. This is the left-pad of rust. Reconsider your life decisions if you need to pull in an external dependency replicable with 30 lines of…

> The data structure never moves an element once allocated

Yours will reallocate every so often, invalidating element references. append_only_vec requires only `&self` to push, and can also be used concurrently. Adding these abilities requires unsafe, so it wants its own module to uphold invariants on private members. Add an efficient well-tested impl and several other traits you might want, and a shared crate is entirely reasonable.

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

#443

Post by josephg »

ben-schaaf wrote: post #410
josephg wrote: post #322

Earlier quoted context omitted.

I’m a big fan of how C# handles this. The standard library is versioned like any other library. Your program is explicit about the major version of the standard library you’re pulling in. And all major versions of the standard library continue to work. For rust, this would mean something like adding std = 1.0.6 to your cargo.toml. The advantage is it means the standard library can deprecate and replace features. Upgr…

Rust already has this, it's called editions. The tricky part is it needs to stay ABI compatible to be able to link dependencies from other editions.

More than that. Rust requires that a program can be compiled from multiple crates, with those crates all targeting different editions. This limits a lot of breaking changes you might want to make. APIs can never really be removed.

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

#444

Post by porridgeraisin »

whstl wrote: post #47
tsimionescu wrote: post #29

Earlier quoted context omitted.

I don't think it's just that, though I agree they are clearly correlated. The reason I don't think it's a sufficient explanation is that there is a clear history of large, 3rd party libraries being created exactly to supplement poor standard libraries. C++ has Boost, Java has Apache Commons (though Java also has a pretty huge standard library), arguably we could even say C has Posix/Win32/Cocoa. I believe there is so…

The important difference IMO is in the small vs big libraries culture. Lots of languages have a bad stdlib but don’t fall into the trap of having thousands of micro libraries. The reason people do it is because it brings clout and money. Just look for articles defending micro libs: the popular ones are by people who make a living on donations, due to maintaining 1000+ packages. And collaborating in larger libs/stdlib…

Yep. It comes down to the way funding flows in the ecosystem.

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

#445

Post by gigaritee »

afdbcreid wrote: post #283
yoyohello13 wrote: post #85

Earlier quoted context omitted.

This was actually the main thing that put me off of Rust. I get the argument for a small std lib. I just also don’t agree it’s worth it. Go seems to handle having a batteries included standard lib just fine.

People confuse what they want. They do not want a big stdlib. The downsides are real (the stdlib cannot make breaking changes), and there are no upsides (except, maybe, for faster compilation, since std comes precompiled). They want more official crates (e.g. `regex` and `libc` are official crates, maintained by the Rust project). And the Rust project does not oppose to that, it just doesn't have the funding.

This is not true. I want a big standard library and I am more than willing to deal with the downsides just like i have with python.

Batteries included ia the only sane way to do programming languages.

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

#446

Post by Orphis »

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…

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 anything changes, or they are not impacted as much since they are using an intermediate language as interface and avoid most ABI issues.

The implementation is fixable though, you can break the ABI and address your issues. A lot of standard library defects are fixed in an unstable ABI mode they have, but that requires you to link it statically or dynamically and then ensure all your shared object dependencies are using the same exact version. It's not trivial for everyone, but many do this (usually the static version).

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

#447

Post by Orphis »

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…

Thinner modular systems also require some good tooling and a good platform that ensures many security properties.

You will be trading a stable and vetted huge standard library for 200 small packages that may all be targets for supply-chain attack. Open-source projects don't all have the resources unfortunately to keep track of all their dependencies, so I'm not sure it's necessarily a more natural fit.

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

#448

Post by chiffaa »

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…

> we should be taking a more “batteries included” approach to language and library design.

Okay, but how do we decide which approach to a problem should be standardised?

Rust's approach of "provide a minimal core to build libraries on top of" provides a fairly significant benefit - flexibility.

A prominent example is async: Rust has three fairly prominent async runtimes (being Tokio for general server-side use, smol for a simple non-work-stealing approach and embassy for embedded). Which one do you make the default? Tokio is very complex and work-stealing is arguably a very bad default in terms of development complexity. smol doesn't fit some workloads because of a simpler execution model. Embassy is way lower level and much more constrained than most applications need. Standardising over one implementation instead of the current (even if still messy due to early portability woes) standardisation around traits and general async semantics would make switching runtimes more problematic, even though the general case is solved with the same approach as Python's

Database access is also a complicated topic. Rust has multiple fairly popular DB libraries. The first two that come to mind are SQLx and Diesel. Both are too complex to be a part of the standard library, both required a fair bit of breaking changes, and if you wanted a raw core to build on top of - you can't really build SQLx on the type of core e.g. Go's database/sql has, you'd be basically forced to implement it all from scratch to handle the compile time type checks anyway

RNG sounds simple, except there are good reasons behind both rand and fastrand existing, and behind rand not being stabilised at 1.0.

DateTime handling is notoriously complicated, has multiple competing implementations (chrono, time, jiff) with various trade offs

Where do you draw the line? What do you standardise and which implementation do you standardise against?

I've seen golang exemplified a lot in adjacent threads, but golang's standard library both has fairly significant issues (json, no set type, very limited CLI flag parsing, UUID took until 1.28) and is standardised around a relatively specific goal (unix server usage)

Dunno, I'm not entirely sold on the whole "extend the standard library" idea for a language meant to run both high level applications and embedded stuff. If anything, recommending blessed.rs more is a better way IMO

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

#449

Post by willtemperley »

wronex wrote: post #428
willtemperley wrote: post #404

Surely non-sandboxed build scripts are just a terrible idea. Both Cargo and npm should look at what Swift Package Manager (SPM) is doing. It’s not perfect but there’s a noticeable absence of supply chain attacks involving SPM, probably partly because it doesn’t use a mutable registry, but I suspect attacks are just more difficult. On the rare occasion a build script is involved it’s run in a sandboxed plugin.

Why would a malicious library author limit their maliciousness to the build script?

They wouldn't, but build scripts are a particularly effective attack vector.
Post reply on HN