This is becoming so common in package managers. I usuaally pik and compile my dependencies in Conan and store them in my own repo for the case of C++.
Malicious Rust crate Arrayref runs a build-time payload
381–390 of 529 posts
Re: Malicious Rust crate Arrayref runs a build-time payload
#382GitHub 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 use, but most of the playbook here was the usual one. We take a snapshot copy of the crate and then purge it from the system.
The security page thing is because the rustsec maintainers were not around or a part of the response as it was occurring. It's pretty normal for a security advisory on rustsec to take some time to merge. We should probably get everyone on the same page about when people not on the rustsec team can merge security advisories, because I do agree that getting them merged quickly is important sometimes.
Re: Malicious Rust crate Arrayref runs a build-time payload
#383Earlier quoted context omitted.
> The bad package version has also just disappeared from crates.io with no indication its been yanked. So, yanked crate versions do have an indication on crates.io. (Here's an example: [1]) The Rust blog post uses the word "deleted", and I'm guessing a bit here, but I think they mean that literally, and that the version here is deleted , not yanked. And I think that would be more appropriate: a yanked crate is still…
> That wouldn't be desirable in the case of a compromised crate: you don't want a download occurring at all. Sure you do; you just don’t want the crate to be made available to people trying to make use of the crate as regular downstream consumers. You still want the crate available for download for analysis . You especially want to be able to deterministically reproduce the vulnerable version of your software that yo…
I mean, we have the crates available for analysis. We take snapshots before deleting them.
We would probably be open to sharing files with those who ask. Probably, I don't know what other team members would think about that. This roughly matches the workflow you propose below where people can ask for access to these things, just a bit more manual.
Any way of keeping it around on the server in a way that is fetchable by cargo is a complete non-starter. Bright red lines are useful in security: _the file is gone_ is way easier to keep secure than "the file is still there in a way that might be fetched if you have the right flags set" now means that that flags mechanism is now security sensitive.
If you'd like us to have a nice page that shows deleted-for-security crates, that's probably a proposal we'd welcome, but it is not really something anyone has time to work on themselves. Right now we just remove them from the db after taking a backup.
Re: Malicious Rust crate Arrayref runs a build-time payload
#384Earlier 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…
I've never seen a non trivial Python or Go project without external dependencies. The dependency tree of comparable Go and Rust projects seem comparable, IMO.
Ok! I had parsed your comment wrong. I see now that you claimed that python and go projects always had at least one dependency, and that go and rust projects had similar dependency counts, but you were not claiming that python and rust had similar dependency counts. Thanks for clarifying, with that I agree my comment was not a good counterexample.
Re: Malicious Rust crate Arrayref runs a build-time payload
#385> arrayref is a small crate of four macros. Why do so many languages fall into this horrible practice?
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.
Rust, on the other hand, might keep you from a subset of buffer overruns, but it will gladly run obfuscated, untrusted code in your name when you wouldn't otherwise expect it to.
As an industry, we need to somehow stop making this mistake.
Re: Malicious Rust crate Arrayref runs a build-time payload
#386I 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…
> There’s no reason why this can’t be replicated elsewhere.
There are plenty reasons. Just not technical reasons.
At the end of the day, people like to feel useful. The ecosystem that attracted communities are those ones where everyone can feel they're contributing back to the communities. That's why the most successful languages, save those backed by big companies, are filled with very small libraries.
No body gets excited making C#/nuget packages.
Re: Malicious Rust crate Arrayref runs a build-time payload
#387We need effect based languages now. It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles. If anyone from epic is reading this please give us a timeline for open sorucing the Verse compiler. In the mean time I think it's possible to hack Cargo and run all build scripts in a microVM. The blast radius will be limited to malicious code in the…
Why does every build have the ability to run arbitrary code by default in the first place? That seems like something you should opt into only under very specific scenarios and even then it should probably be built around a WASM sandbox or microVM (as the parent suggested).
> Why does every build have the ability to run arbitrary code by default in the first place?
Nearly every time that you see a build script in use it's to support building C code, which has no standard build process and which often involves executing shell commands, and the shell itself is an arbitrary code execution environment with arbitrary access to the network.
Re: Malicious Rust crate Arrayref runs a build-time payload
#388Earlier quoted context omitted.
I mean, yes, update your dependencies. But probably after a week or so after they've been release and tested by the first penguins willing to jump into the ocean.
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
#389This is an developer environment worm, the problem is the terminal has no data-isolation.
Your development tools should not be able to access your keys.
I have built a model for providing data-isolation on nixos:
https://decentstat.es/posts/shai-halud-nix-housing/
(non vibecoded)
Re: Malicious Rust crate Arrayref runs a build-time payload
#390Earlier quoted context omitted.
The idea that Rust has a small standard library is a weird meme. Rust has an enormous standard library. Look at any Rust release and you'll see dozens of new library APIs added, and consider that Rust has about nine releases a year, meaning that Rust adds over a hundred APIs per year, and has consistently for the past ten years. Rust frequently adds things that obviate popular crates, most recently the cfg_if crate w…
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.
JSON support is provided by serde_json, which is owned by dtolnay, a longtime member of the Rust standard library team. Regex is provided by the regex crate, owned by burntsushi, a longtime member of the Rust standard library team. Directory walking is provided by walkdir, also owned by burntsushi. RNG is provided by the rand crate, owned by the rust-random organization, also full of longtime Rust contributors. CLI argument parsing is provided by the clap crate, owned by epage, the lead developer of Cargo. These aren't randos, these are all de-facto first party libraries. You can trust these developers as much as you trust any random owner of any random Debian package.