Live data from Hacker News

Malicious Rust crate Arrayref runs a build-time payload

safedep.io

511–520 of 529 posts

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

#511

Earlier quoted context omitted.

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

You’re not even attempting to discuss the topic, more interested in make meta attacks about me personally. So I think it’s now safe to assume you’re just trolling. In which case I’ll return the favour by adding you to the ignore list. Pity though, I would have been interested to talk to someone who was passionate about this topic.

> You’re not even attempting to discuss the topic

This would be why I started the thread.

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

#512
post #18

Earlier quoted context omitted.

The languages that have a poor standard library support have this issue and other languages encourage you to import tons of libraries to fix the problem. This is why Javascript and Typescript suffer from this the most and has little to nothing to do with "popularity" and likely 9/10 of these npm packages import an external library. Golang on the other-hand is just as popular and has a stronger standard library which…

Maybe it wouldn't matter either way if people stopped putting untrusted executable code into basic build processes. You could get rid of a huge portion of the go standard library and have a massive ecosystem of leftpads, but the fact that `go build` can easily be run in off-line mode and doesn't execute any code other than the go toolchain itself, means you have a fundamentally more trustworthy ecosystem overall. Rus…

I do not think this is a "mistake". This is the result of different priorities.

Rust has done nothing to make me safer (although I agree that memory safety is desirable) and the supply chain issues make me less safe.

Still parts of the industry want it. If your business is putting locked down app stores and media-consuming devices in everybody pockets, than memory safety is much more important than for the rest of us.

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

#513
post #510

Earlier quoted context omitted.

Ok, so I created an empty cargo project and added serde_json, regex, walkdir and rand. This added 28 crates, several of these from the same authors. If the absence of these features caused 1000s of dependencies, then where are the remaining 972? When I look at a project at work then what inflates the dependency tree is a combination of a whole webserver application stack plus SDKs consisting of dozens of crates. Thos…

28 crates for 3 of the most common functionalities. And it would have been 0 crates in .NET or Go. Even after adding a web server.

> 3 of the most common functionalities.

Four. Though you initially asked for five features, so let me add lexopt, which brings the number up to 29.

> That's why projects end up with 100s of crates, sometimes 1000s.

If your argument is "out of 1000s of dependencies 29 could be easily removed" then it does sound a lot less of a deceive change when it comes to supply chain security.

And even getting those 29 right is hard. For example people do want regular expressions with lookaround assertions, but most implementations suffer from runtime blowups (resulting in ReDoS attacks) and improving on that is a fairly recent research[0], so this is hardly a trivial and settled thing to implement. So often there's a tradeoff between choosing more powerful regular expressions and DoS-resistant ones, not one standard.

[0] https://systemf.epfl.ch/blog/re2-lookbehinds/

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

#514
post #425
post #193

Earlier quoted context omitted.

Namespacing. Mandatory namespacing. It's an essential prerequisite for any kind of reputation building and managememt, before you even get into the gritty technical or security details. And it has to be mandatory. Top-level package names will always have more cachet. Developers are suckers for good package names, literal or imaginative. Plus it helps address, but by no means completely solves, name and typo squatting…

I'm not sure what namespacing has to do with anything here. Namespacing would not even remotely have prevented anything like the OP.

It would make it easier to, as a matter of policy, to stick to components from teams like boost or Apache or Google, i.e. groups with known reputations, reputations for having long-term, active involvement and maintenance than crates put out by single individuals or startups. And if and when a project was compromised, it's more likely to be discovered in a timely manner.

To build reputations (good or bad), an ecosystem needs branding--a reliable way to connect products to an identifiable group with a history. Reputations are crucial if you're just downloading blobs of code in a fast-paced environment, because you're not directly analyzing the code, certainly not every update, and usually not even initially. It's why you don't download software from random websites to run.

Linux and BSD distributions that packaged code were trusted (to varying degrees) to vet code through their package maintainers. People apt install packages with m less trepidation and risk than if they pulled random code off Github. The distro reputations tell you something, at least something much more credible that what availability on crates.io and github.com tell you.

Technical security processes, which are also lacking, are no substitute for social processes. They're complimentary; you need both. But the most rudimentary and important prerequisite for building more secure social processes is completely absent in the Rust crates ecosystem.

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

#515
post #114

GitHub really needs something finer-grain then just pretending the repo never existed during these incidents. [1] The bad package version has also just disappeared from crates.io [2] with no indication its been yanked. There's no security advisory there either [3] "No advisories found for this crate." I feel crates.io was unprepared for a security incident like this since they're managing the response [4] [1]: https:…

If anyone wants to create a revision to RFC 9110 :) HTTP/1.1 309 Security Advisory Location: https://acme/aaargh-another-advisory

410 Gone seems sufficient to differentiate from "this never existed".

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

#516

Earlier quoted context omitted.

If anyone wants to create a revision to RFC 9110 :) HTTP/1.1 309 Security Advisory Location: https://acme/aaargh-another-advisory

410 Gone seems sufficient to differentiate from "this never existed".

But I want to specifically signal a security concern to the requesting party. For example, a artifact proxy (like Artifactory or CodeArtifact) can use this response to warn developers.

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

#517

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=49374811 (Oh and btw, proc macros also run arbitrary code.)

There's no good reason a proc macro can't run in a no-IO sandbox by default. None. Doesn't require a language change. Doesn't require some microvmcapabilityeffect BS. It requires looking people straight in the eye and saying "no" when they complain about needing to prompt for privileges.

No good reason? Here's a list: https://github.com/dtolnay/watt#remaining-work

(It mostly boils down to "somebody needs to do it". I'd really like proc macros precompiled to wasm by crates.io…)

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

#518

Earlier quoted context omitted.

410 Gone seems sufficient to differentiate from "this never existed".

But I want to specifically signal a security concern to the requesting party. For example, a artifact proxy (like Artifactory or CodeArtifact) can use this response to warn developers.

Structured data in body or HTTP header is plenty for that, no need for a HTTP status.

For example, if we were talking about a human-readable /crates/* page, returning 410 Gone with a HTML page explaining the situation to a human, that page could have a JSON-LD snippet explaining the same to a computer.

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

#520

Earlier quoted context omitted.

[flagged]

As a person who doesn't like Rust very much, no, it doesn't suck. Some of its features make some folks very excited for very right reasons, and evokes "Silver Bullet Syndrome" in others for all the wrong reasons. People weaponizing Rust rewrites with permissive licenses is another problem, but it's not about the programming language itself.

No. It actually does suck.

See how opinions work?

Post reply on HN