Live data from Hacker News

Malicious Rust crate Arrayref runs a build-time payload

safedep.io

491–500 of 529 posts

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

#491

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. It works for something like Go

It, as you put it, works for Go because its designers took a hard stance and decided that it was a language for network systems and you're on your own if you want to make it do other things. Nobody needed to agree because it was already chosen for you.

> For Rust, well I would like to prioritise features for embedded development, someone else might want game dev features (geometry and physics stuff), yet another person wants data science things. And so on.

But does Rust need to be all things to all people? The Go ecosystem has a separate standard library under the Tinygo project for those who want to prioritize embedded development. Even if there was convergence on Rust as a language, it doesn't technically need a singular standard library. There can be a distribution for embedded developers, a distribution for game developers, etc.

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

#492

Earlier quoted context omitted.

> Nice sarcasm but you’re not actually addressing a solution to the problem I raised. Are you not concerned about an asteroid impact rendering you extinct during your next Rust build? Why not? That's the same level of relevance as your supposed concern. > So you’re now saying it’s ok to have exploits compiled into your application as long as it’s sandboxed? You need to act like it is compromised in all cases, just li…

> Are you not concerned about an asteroid impact rendering you extinct during your next Rust build? Why not? That's the same level of relevance as your supposed concern. That’s a strawman argument and you’re still dodging the question. > You need to act like it is compromised in all cases, just like everything else. No. I act like compromised code is a legitimate risk regardless of how well your build pipeline is san…

> That’s a strawman argument and you’re still dodging the question.

Hmm . . .

> 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust.

That is a straw man, right there, designed to attempt to ignore the substance of the original statements. Your hypocrisy is unbelievable.

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

#493

Earlier quoted context omitted.

> Are you not concerned about an asteroid impact rendering you extinct during your next Rust build? Why not? That's the same level of relevance as your supposed concern. That’s a strawman argument and you’re still dodging the question. > You need to act like it is compromised in all cases, just like everything else. No. I act like compromised code is a legitimate risk regardless of how well your build pipeline is san…

> That’s a strawman argument and you’re still dodging the question. Hmm . . . > 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. That is a straw man, right there, designed to attempt to ignore the substance of the original statements. Your hypocrisy is unbelievable.

I was replying to someone who suggested sandboxing by raising a couple of places their suggestion falls short.

Did you even read this thread? Or just assumed “anyone suggesting sandboxing wouldn’t work must be an idiot”? Because you’ve managed to misrepresent my comments at every opportunity.

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

#494

Earlier quoted context omitted.

Because many many builds end up doing something just a little weird that the build system cannot handle by default. Ideally the build system would be fully property/dependency based and so it wouldn't have to run arbitrary code. In the real world everybody has something weird about their build that the build system cannot make work. This is partially because for nearly every project the build system is something they…

I mean, I understand the need for an escape hatch, but it’s strange to me that it’s the default and that it’s unsandboxed. Feels like build scripts should be treated like CGo in Go—a rare escape hatch that people strongly try to avoid so that downstream builds are better. To that end, Go doesn’t even have macros or code generation and it gets by reasonably well without any build scripts should support—I understand th…

Until a few years ago abuse of the escape hatch was seen as something theoretically possible but not realistic. Sadly attackers have abused trust and so even though most people are honest we can no longer trust anybody.

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

#495

Earlier quoted context omitted.

> That’s a strawman argument and you’re still dodging the question. Hmm . . . > 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. That is a straw man, right there, designed to attempt to ignore the substance of the original statements. Your hypocrisy is unbelievable.

I was replying to someone who suggested sandboxing by raising a couple of places their suggestion falls short. Did you even read this thread? Or just assumed “anyone suggesting sandboxing wouldn’t work must be an idiot”? Because you’ve managed to misrepresent my comments at every opportunity.

> I was replying to someone who suggested sandboxing by raising a couple of places their suggestion falls short.

No, you created two straw men and attacked them, then got upset at me pointing this out, while accusing me of doing exactly what you are doing.

> Or just assumed “anyone suggesting sandboxing wouldn’t work must be an idiot”?

Why, when we could assume malice instead?

> Because you’ve managed to misrepresent my comments at every opportunity.

Maybe it's your comments that are the problem.

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

#496

Earlier quoted context omitted.

I was replying to someone who suggested sandboxing by raising a couple of places their suggestion falls short. Did you even read this thread? Or just assumed “anyone suggesting sandboxing wouldn’t work must be an idiot”? Because you’ve managed to misrepresent my comments at every opportunity.

> I was replying to someone who suggested sandboxing by raising a couple of places their suggestion falls short. No, you created two straw men and attacked them, then got upset at me pointing this out, while accusing me of doing exactly what you are doing. > Or just assumed “anyone suggesting sandboxing wouldn’t work must be an idiot”? Why, when we could assume malice instead? > Because you’ve managed to misrepresent…

> No, you created two straw men and attacked them, then got upset at me pointing this out, while accusing me of doing exactly what you are doing.

I’m not upset at you. I’m just saying you’ve misread the thread and then proceeded to make invalid remarks because of that.

> Maybe it's your comments that are the problem.

I’ve managed to have a civil conversation on this topic with everyone else. Including the person you think I insulted (which I didn’t).

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

#497
post #280

Earlier quoted context omitted.

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…

Actually I think this is more of a culture thing. Or maybe "is also" a culture thing. One of the core tenets of early Go was the maxim "a little copying is better than a little dependency". Probably because of this stance, they didn't even HAVE a dependency-management solution for years I strongly agree the fewer dependencies the better, on average.

It absolutely is a culture thing. I've seen many threads asking about backend frameworks in Go, and every time there were lots of answers akin to "screw framework dependencies, stdlib is more than enough".

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

#498
post #36

Rust seems barely better than Node in this regard. Go or .Net or anything with a robust standard library seems like the way to go for most projects.

Cargo (and PyPI) is undeniably better than NPM, which is just shockingly bad for cultural reasons. Yet it's not safe, and it's subject to the same class of exploit, as we're seeing. Indeed, the solution is to get away from the wild soup of author-managed dependencies and go with something with an audited collection of software that is maintained by separate human beings from the known-vulnerable hackers writing the s…

Is Rust ecosystem really that much better, if at all? This is a genuine question.

You can't disable build.rs, Rust Analyzer executes proc macros as soon as you open the project (and it needs to execute them in order assist the developer), minimum days since release has not yet made it into stable (though luckily it is planned for 1.100), and the number of project dependencies goes easily into several hundreds (still better than npm's few thousands, though, and I know that some deps are from Cargo workspaces), and on top of that, lots of packages stick to 0.x version for years.

Personally I see Rust community's packaging and security culture more akin to that of JS than to Java et al.

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

#499

Earlier quoted context omitted.

> I was replying to someone who suggested sandboxing by raising a couple of places their suggestion falls short. No, you created two straw men and attacked them, then got upset at me pointing this out, while accusing me of doing exactly what you are doing. > Or just assumed “anyone suggesting sandboxing wouldn’t work must be an idiot”? Why, when we could assume malice instead? > Because you’ve managed to misrepresent…

> No, you created two straw men and attacked them, then got upset at me pointing this out, while accusing me of doing exactly what you are doing. I’m not upset at you. I’m just saying you’ve misread the thread and then proceeded to make invalid remarks because of that. > Maybe it's your comments that are the problem. I’ve managed to have a civil conversation on this topic with everyone else. Including the person you…

> I’m just saying you’ve misread the thread and then proceeded to make invalid remarks because of that.

Once again you accuse me of exactly what you have been doing.

The other commenter calling your response "disingenuous" is putting it mildly.

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

#500
post #483

Earlier quoted context omitted.

Updating every dependency for every kind of CVE is a brute force method for people and organisations that don’t understand the attack surface of the programs they’re producing

And vendoring without having any idea of what is in there and doing no monitoring is peak engineering?

Who is doing what you’re describing? The reason I can confidently freeze and offline stuff is because I’m not taking in whole frameworks, I’m selecting things carefully, and generally do end up reading at least most of the source

And what ‘monitoring’ are you going to be doing besides things like CVEs?

Post reply on HN