Live data from Hacker News

Malicious Rust crate Arrayref runs a build-time payload

safedep.io

501–510 of 529 posts

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

#501
post #428

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 won't, but the less attack vectors, the better.

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

#502

Earlier quoted context omitted.

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

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.

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

#503

Earlier quoted context omitted.

Holding periods for new updates are a good idea, but I would also prefer having a tool that could provide diffs of the entire project state pre- and post-update; including transitive dependencies being added or removed. Git diffs won't show you that information, by design.

Why not? Cargo.lock includes the transitive dependencies, and Cargo itself reports everything that changes when you do an upgrade. Those are version changes, not code diffs, but it seems entirely tractable.

I specifically meant a tool that shows code diffs for transitive dependencies.

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

#504

Earlier quoted context omitted.

Ultimately I think devs need to think about their dependencies and decide which ones get pinned and a serious review before pulling. If the thing has got binaries, it gets a serious review. If it does anything with cryptography, it gets a serious review... etc. I don't think automatic updating is a good idea at all. It's just the honor-system, and trust is a security flaw.

Exploits can be shipped in any type of dependency. Remember the compression exploit that affected even SSH? The problem is your solution depends on the honor-system. Ie “trust me, because I’m just a YAML mashaller. Why would I want to inject a crypto miner?” That’s why package databases exist. They are meant to be centralised databases of peer reviewed and CVE checked resources. But Gos approach pushes all that respo…

It's interesting how this plays out with C/C++. There's not really a package manager, and so the host system has to have vetted packages. It moves the burden on to the system maintainer.

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

#505

Earlier quoted context omitted.

Exploits can be shipped in any type of dependency. Remember the compression exploit that affected even SSH? The problem is your solution depends on the honor-system. Ie “trust me, because I’m just a YAML mashaller. Why would I want to inject a crypto miner?” That’s why package databases exist. They are meant to be centralised databases of peer reviewed and CVE checked resources. But Gos approach pushes all that respo…

It's interesting how this plays out with C/C++. There's not really a package manager, and so the host system has to have vetted packages. It moves the burden on to the system maintainer.

Yup. It’s a system that worked when it was relatively safe to assume a chain of trust. But it’s not scaling to the era of AI agents writing patches, nor the increasingly number of attacks against existing foundational packages.

We really do need to rethink the security model behind open source.

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

#506
post #377
post #269

Earlier quoted context omitted.

Yep. Sorry for the spam, but look at this, compiling "yazi" from source (ie a relatively simple TUI file manager) 676 dependencies: Downloaded by_address v1.2.1 Downloaded block-buffer v0.12.1 Downloaded block-padding v0.4.2 Downloaded adler2 v2.0.1 Downloaded color_quant v1.1.0 Downloaded blowfish v0.10.0 Downloaded byteorder v1.5.0 Downloaded bytemuck_derive v1.12.0 Downloaded futures-sink v0.3.34 Downloaded bs58 v…

You can't imagine how much your example calls home! https://github.com/hbbio/rc In my opinion, library authors should really minimize the amount of dependencies they have. Back to TypeScript, we are also the authors of https://github.com/okcontract/cells and we made a point of almost not having dependencies or even devDependencies.

Yes this is the way to go. As few deps as possible.

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

#507

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…

If those transitive dependencies are baked into the language runtime, how is anything materially different? You just shift the vector around.

There are more differences.

Packages can release updates arbitrarily, while standard libraries tend to have longer release cadences.

It's also more difficult to put arbitrary code into an stdlib, because stdlibs are scrutinized better.

Also, it's harder for some random anonymous developer to gain push access to stdlib repository.

One of the reasons so much Rust code is in libraries is not because there are no people to write it (duh), but because putting these in std commits maintainers to keeping backwards compatibility and slows down included package's release cycle.

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

#508

Earlier quoted context omitted.

I think having production-grade implementations makes a huge difference also. Go’s net/http in the std lib feels like a good example of that, though I’m fairly new to go still. But it seems net/http still gets pretty big updates despite something like Chi being available as an external lib. Odin is doing this as well, even including raylib in the std lib. Odin is even more primed to keep you on the std lib as it does…

So I went to have a look at Odin and was mind blown at the lispiness in the hellope example. A list of operators defined as "program"; that are applied to the accumulator then printed. It's a striking first impression for me and I want to see what the Odin people have cooked up.

Odin has been a masterpiece so far! Ginger Bill has a massive update coming in for it Jan 2027 as well. :) I think it's definitely going to take off in the next few years.

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

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

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.

Post reply on HN