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

461–470 of 529 posts

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

#461

Post by pjmlp »

VorpalWay wrote: post #455
pjmlp wrote: post #415

Earlier quoted context omitted.

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.

It works good enough for stuff I would be using Java or .NET for.

Not every application requires internationalisation, especially server code or internal company tools.

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

#463

Post by survirtual »

Manishearth wrote: post #382
cube00 wrote: 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:…

The response was managed by the security-response team working with the infra team and the Rust Foundation's Security engineer. Tobias from the crates.io team was also involved but on vacation so it was not as active. This is normal. What makes you say we were unprepared? We have been deleting malicious crates for a while. This is the first time those crates have wormed their way into an actual real crate that people…

The crates.io page and version history should have an entry, like red with an ! and a cross through with an advisory note explaining the security issue, accessible via the api as well so it is clear what happened.

The main crate entry should also contain a security advisory at top. I looked at the crate and it just looked normal; I had to dig to find the exact impact surface, and if I wasn't informed via secondary means (hackernews) I would not have known. This is unacceptable for a mature package management system.

Luckily I was unaffected in this case.

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

#464

Post by imtringued »

sarahsoup wrote: post #416
rvz wrote: 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…

C has a piss poor standard library and doesn't have this problem. Make dependencies annoying to use and it forces people to be more disciplined about them and if you do insist on a package manager you should not support transitive dependencies at all, packages should be self contained.

Transitive dependencies aren't the problem. C projects often have transitive dependencies twelve packages deep.

The problem is that these languages have repositories are both free for all and have no consumer side vetting out of the box.

Linux distributions have maintainers that vet the packages and that's why you can blindly download transitive dependencies with your OS package manager.

But you can't do the same with the AUR. The AUR workflow requires you to actually read the PKGBUILD.

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

#465

Post by imtringued »

ajross wrote: post #36
christophilus wrote: post #9

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…

There is a reason why software foundations like the Apache Software Foundation exist and this is one of the bigger ones.

Turns out, it just doesn't make sense to be an independent open source developer of a critical dependency anymore. You can write the software yourself, but you can't publish it yourself.

All the Rust library crate developers will have to get together and start their own software foundation.

I personally don't believe the standard library argument is very convincing, because even with Java the latest newly added HTTP client has some blatant problems that require you to go with a wrapper like Methanol.

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

#466

Post by imtringued »

bilkow wrote: post #215
bel8 wrote: post #150

Earlier quoted context omitted.

It still lacks basic functionality like a JSON parser, regex, directory walker, rnd generator and cli arg parsing. I won't mention lack of date/time lib because that's complex and changes often. That's why projects end up with 100s of crates, sometimes 1000s. This might not be a well received fact in Rust community, but it's a fact nonetheless.

My personal opinion on each of those: JSON: there are a ton of different ways to do serialization and deserialization, each with their own tradeoffs, and serde (the most popular) is far from universally agreed upon. The same goes for JSON specifically, there are many different serialization formats with different tradeoffs. regex: Owned by the rust-lang organization already. You get the benefits of trust (if you trus…

A big issue here is the complete lack of namespacing. You have these sub crates with zero ability to know whether they are related to a given organization/author/project.

I mean look at the people defending the lack of namespacing:

https://samsieber.tech/posts/2020/09/registry-structure-infl...

One of the most obvious problems with the lack of namespacing is that if you have a group of crates belonging together, you have to reserve them all at once otherwise an automated script could detect your package and add common suffixes like -sys and take the name even though you got the non sufficed name.

You cannot add name spacing by just prefixing everything with your preferred prefix, because anyone can publish under that prefix.

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

#467

Post by nh2 »

josephg wrote: post #348
7373737373 wrote: post #253

Earlier quoted context omitted.

That's why languages need sandboxing at runtime as well

Yes, or the compile time equivalents. Rust’s safety gets you most of the way there. We just need a capability model in the language, a more limited std and a way to ban untrusted 3rd party libraries from using unsafe code without explicit permission. I dream of a world where a function with the signature of add(u32, u32) -> u32 can’t burn my house down and steal my wife. Functions should only have access to their arg…

You have just reinvented "Safe Haskell" from 2012.

It guarantees that pure functions are pure.

https://www.microsoft.com/en-us/research/publication/safe-ha...

https://downloads.haskell.org/ghc/latest/docs/users_guide/ex...

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

#469

Post by josephg »

nh2 wrote: post #467
josephg wrote: post #348

Earlier quoted context omitted.

Yes, or the compile time equivalents. Rust’s safety gets you most of the way there. We just need a capability model in the language, a more limited std and a way to ban untrusted 3rd party libraries from using unsafe code without explicit permission. I dream of a world where a function with the signature of add(u32, u32) -> u32 can’t burn my house down and steal my wife. Functions should only have access to their arg…

You have just reinvented "Safe Haskell" from 2012. It guarantees that pure functions are pure. https://www.microsoft.com/en-us/research/publication/safe-ha... https://downloads.haskell.org/ghc/latest/docs/users_guide/ex...

Oooh I didn't know that was a thing!

Yes, I want this but in a fast, compiled systems language like rust.

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

#470

Post by Filligree »

VorpalWay wrote: post #451
Orphis wrote: post #446

Earlier quoted context omitted.

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

I use urllib.request. It works fine, it’s always available, and I don’t need to push it through an audit.
Post reply on HN