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

401–410 of 529 posts

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

#401

Post by kelnos »

__david__ wrote: post #256
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 think Go ends up with fewer dependencies mostly because there is more friction in finding them. With rust (and npm) you just "cargo search xxx", then "cargo add xxx". Go makes you web search and poke around github looking for something. It's not onerous or anything, but just that extra step slows things down just a bit. C projects tend to have the least because it's even more annoying to add them and you have to cr…

I don't really agree. You reach for a dependency when you need to do something non-trivial and the stdlib doesn't have what you need (or the stdlib implementation is bad). You don't just sit around running `cargo search` for fun.

I think the ease of adding dependencies does drive the idea of "microdependencies", where you have many dependencies that do one little thing, and then those dependencies likely have their own small dependencies.

Whereas in the C world, you'll probably have a smaller number of dependencies, but it's likely that some of them are very big dependencies that offer a lot of functionality (like glib, for example).

I could maybe see the argument that ease of adding dependencies discourages people from writing small things themselves. Good ol' left-pad comes to mind. In an ecosystem like C, I'd just write that algorithm myself, over and over and over, because pulling in a dep just for that feels annoying.

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

#402

Post by kelnos »

cosmic_cheese wrote: post #209
mightyham wrote: post #191

Earlier quoted context omitted.

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…

It’s being used for a wide variety of other purposes however, and so perhaps it’s time to adapt to that reality. While overhead is a real concern, I think it’s often blown out of proportion. Once a language achieves a certain baseline of stability and isn’t in constant flux and the standard library matures, changes become infrequent and maintenance load is low. The work is heavily front-loaded.

> It’s being used for a wide variety of other purposes however, and so perhaps it’s time to adapt to that reality.

Who is going to pay for the resources to make that happen, though? The reality is that the bulk of Rust contributions come from a fairly small group of people, many of whom are volunteers. Some are Mozilla employees, and they don't have all the funding in the world.

Yes, it would be great if every open source project could magically be able to meet the needs of all its users, but that just isn't how it works.

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

#403

Post by socalgal2 »

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…

If rust has a well featured standard library, why do the rust docs need to download 741 crates?

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

#404

Post by willtemperley »

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.

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

#405

Post by kelnos »

Pannoniae wrote: post #302
afdbcreid wrote: post #295

Earlier quoted context omitted.

> Who said a standard library can't make breaking changes? The std making a breaking change is the language making a breaking change. Most mainstream languages guarantee stability, certainly Rust. > your program is smaller How so? It doesn't matter if the code is in std or a crate. > better security because a random kid can't pwn your deps, quality and interoperability That's exactly what I said: you don't need bigge…

>Most mainstream languages guarantee stability, certainly Rust. That's their mistake, right there... When you're upgrading software, you presumably want a better version. You can't have something better without changing it. It's a logical contradiction. >It doesn't matter if the code is in std or a crate. It very much does because you don't need 95% of the random stuff in the crates. Even for something like rand, you…

> That's their mistake, right there...

No it's not. It's exactly what I want, at least.

> When you're upgrading software, you presumably want a better version.

Sure...

> You can't have something better without changing it. It's a logical contradiction.

No, that makes no sense. When I upgrade the rust compiler, I might want it to compile programs faster. I might want its borrow checker to be smarter so that it accepts more valid programs than it did before. I might want to have some new language features (like if-let chaining or GATs).

What I absolutely do not want is to have to change the code in my programs so that it can be successfully compiled by the new version of the compiler.

Yes, certainly there are some times in the lifecycle of a piece of software that there's an improvement that requires a breaking change, but you believe is important and necessary, so you bite the bullet and do it. But you burn user goodwill every time you do that (maybe not your goodwill, but most people are not like you in this regard), and create work for people that they would probably prefer not to do. You also create fragmentation, because people aren't going to upgrade their new stuff to the new version all at the same time, and some people may never upgrade. All of this has costs, and deciding never to make breaking changes (or at least keep them to the absolute bare minimum) is a reasonable choice in the face of those costs.

Maybe it's not the choice you personally would have made, but it doesn't mean it's a mistake. They just value a different set of things than you do, in a completely reasonable way.

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

#406

Post by kelnos »

pjmlp wrote: post #328
dwattttt wrote: post #299

Earlier quoted context omitted.

Add more and more to a standard library, and you're going to start losing your "works everywhere".

Naturally there is a balance, still I think Java, .NET, Python, Go, Smalltalk, manage quite well, while having subsets to slim down when needed for specific deployment scenarios like embedded devices.

It's interesting that you include Java in there, as I've worked on some pretty bog-standard Java code bases where the dependency tree didn't look all that different from a cargo project's.

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

#407

Post by kelnos »

cosmic_cheese wrote: post #247
TZubiri wrote: post #235

Earlier quoted context omitted.

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

You seem to be under the mistaken impression that the Rust team is some huge organization. They're not. They are certainly larger than you or me sitting behind our keyboards at home, but they don't have endless resources, and they are always stretched pretty thin.

So sure, you want, say, a JSON library in Rust std? Who's going to shepherd it in and then maintain it? Well, you could hope that the people behind serde_json might want to do it, but what if they don't? Where are you going to get the people with the time to do it?

For something like Go, the answer is easy: tap into the money printer that is Google, and hire more people. But for Rust? Hell, the core team has probably only declined in number over the years (Mozilla layoffs, for one thing).

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

#408

Post by kelnos »

cosmic_cheese wrote: post #379
josephg wrote: post #344

Earlier quoted context omitted.

The counterpoint is that whatever std invents is probably not going to be as good as what moviated people in the community make. The rand crate is my favorite example of this. They have a whole bunch of different rngs. All rated by quality and performance. Some are csrngs and some aren’t. It’s a delight. “Batteries included” languages don’t come close. Then there’s serde - which uses a clever technique with traits to…

> Maybe std should pick up the best crates from the community and bring them in house? This might be a good idea. But also maybe not. Since serde came out, several other crates have found ways to crush its performance numbers. Often by 2-5x if memory serves. What a relief we didn’t immortalise the slow version of serde, right? I think periodically rolling in the best crates is the way. Don't immortalize anything, tho…

> Don't immortalize anything, though. Always reserve the freedom to swap out integrated crates when something better rolls around.

That's a non-starter, though. Once it's in std, it's not an "integrated crate", it's in std, just like any other part of it. Removing it is a breaking change, and I don't want a new incompatible Rust major version every year or two (or even five or ten, honestly). (Of course, Rust has editions to make breaking changes possible without affecting old code, but there are limits to what you can change in editions.)

Pretty much every language ecosystem fights really hard to maintain backward compatibility as they evolve, and every time they fail to do that, it causes headaches, sometimes for years. Python 2->3 is of course the canonical painful example of that, but there are others that are instructive if you only take the time to research.

(And before you mention something like Zig, which changes incompatibly frequently enough, remember that the author has made an active decision to remain pre-1.0 unstable. That's one reason why the Zig community isn't that large. That's not me looking down on them; that's an active choice they've made, and they're free to make that choice. But bigger/popular languages like Rust can't go back in time and decide to be like that.)

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

#409

Post by jurgenburgen »

kibwen wrote: post #273
jurgenburgen wrote: post #173

Earlier quoted context omitted.

That’s not solving the problem, that’s avoiding it by making it the users fault if they make a mistake.

Rust, like C, C++, and every other systems programming language, is all about giving users the power to make mistakes. The philosophical difference when it comes to Rust is simply that it tries to force the user to flip off the safety on the gun before letting you shoot yourself in the foot. A Cargo config option letting people opt-out of sandboxing would be fully in line with Rust's philosophy.

Having a dangerous flag as a backwards compatibility flag is okay. I don’t think making users decide between multiple levels of sandboxing is constructive, they will just be trained to ignore it.

This is the kind of decision users likely don’t understand without looking at the source code of a crate and it’s bad UX to push it to be their responsibility.

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

#410

Post by ben-schaaf »

josephg wrote: post #322
Pannoniae wrote: post #291

Earlier quoted context omitted.

The fallacy is assuming that standard != unchangeable. One can very simply....make breaking changes. Yes it will require some work to update but that's already the case when you upgrade library versions. The dependency hell doesn't help anyone here, the downside is much worse - lots of bloat, overgeneric libraries and awful supplychain security.

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.
Post reply on HN