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?
Malicious Rust crate Arrayref runs a build-time payload
501–510 of 529 posts
Re: Malicious Rust crate Arrayref runs a build-time payload
#502Earlier 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.
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
#503Earlier 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.
Re: Malicious Rust crate Arrayref runs a build-time payload
#504Earlier 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…
Re: Malicious Rust crate Arrayref runs a build-time payload
#505Earlier 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.
We really do need to rethink the security model behind open source.
Re: Malicious Rust crate Arrayref runs a build-time payload
#506Earlier 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.
Re: Malicious Rust crate Arrayref runs a build-time payload
#507Earlier 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.
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
#508Earlier 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.
Re: Malicious Rust crate Arrayref runs a build-time payload
#509Re: Malicious Rust crate Arrayref runs a build-time payload
#510Earlier 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…
And it would have been 0 crates in .NET or Go. Even after adding a web server.