Rust suffers from the same faults as the JS ecosystem. Any significant crate imports hundreds if not thousands of dependencies. The probability that one of the authors gets targeted by AI-assisted attacks is just too high. Also most of these dependencies provide a breadth of features that the end package does probably not need.
My experience has been that it has a major advantage, in that freeze + offline actually work properly. You can collect the dependencies you need once, put them in version control and never ever talk to remote registry again
Rust finally got hit... This was motivating me to swap away from Rust towards because of the huge number of dependencies. It seemed inevitable. Ginger bill was right, https://www.gingerbill.org/article/2025/09/08/package-manage...
The author proposes to reinvent the wheel and depend on stale dependencies, which are EOL. Neither of that is an acceptable solution with LLM-based Agents being able to produce exploit(ExploitGym) chains in minutes from known bugs. The other issue is that Rust's forces the user to provide more information and APIs are usually kept generic for systems programmer, so standardizing things is not as straight-forward compared to Go where you can assume a memory-management, a virtual thread runtime and mostly ignore dynamic dispatching.
We 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…
Cargo desperately needs sandboxing for build.rs scripts. It’s been attempted before, but didn’t go very far¹. ¹ https://rust-lang.github.io/goals/2024h2/sandboxed-build-scr...
build.rs by design can run absolutely anything. There tons of build.rs scripts that invoke a whole-ass C compiler toolchain to build and link C dependencies... It isn't so much a question of sandboxing build.rs, as fundamentally changing the way that foreign dependencies are integrated into the rust toolchain (i.e. moving from a rust-centric system like Cargo to something more general like buck2)
The vast and overwhelming majority of build scripts are building C code, so the other solution is to move away from integrating with C dependencies to native Rust dependencies, in which case adding friction to build scripts would be less noticeable.
Cargo desperately needs sandboxing for build.rs scripts. It’s been attempted before, but didn’t go very far¹. ¹ https://rust-lang.github.io/goals/2024h2/sandboxed-build-scr...
This is exactly what PMG is designed for ie. install/build time process level sandboxing. It currently doesn't support cargo, but I believe the challenges are same. Here is my learning building PMG: Sandboxing is good when the workload is predictable, and the goal of sandbox is to guard against exploitation of vulnerabilities, like sandbox protecting chrome tabs (renderers). But unfortunately build scripts are not pr…
The "How PMG Works" section on Github does not actually explain how it works
Never going to work. Crates must be audited for behavior before use.
cargo add + rust-analyzer instantly executes build.rs before you have a chance to audit the code. Cargo, please PLEASE give me a way to disable third-party build.rs and whitelist the ones I need. And please loudly mark any update that adds a build.rs where there was none before.
cargo-deny can audit build scripts, but unfortunately not prevent execution of malicious build scripts exactly for the reason you gave. It could still help if you only ever use cargo add and update in a sandbox.
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:…
> GitHub really needs something finer-grain then just pretending the repo never existed during these incidents.
Google should read this too. They simply remove Android apps and Chrome extensions without a single word. No page explaining why they removed it, if i was at risk.
Cargo desperately needs sandboxing for build.rs scripts. It’s been attempted before, but didn’t go very far¹. ¹ https://rust-lang.github.io/goals/2024h2/sandboxed-build-scr...
Sandboxing just build.rs would only be be a minor inconvenience for the attacker, nothing more. The attacker can always as easily compromise the binary you build and as soon as you run it (e.g. in a test) you are owned. It would be a big pain for many that are in the unfortunate position to really need build scripts, though.
At the very least, it wouldn't be overly onerous when adding a dependency that requires a build script to require an opt-in via Cargo.toml, e.g. `build-script = true`. You'd make it viral so that any transitive dependency that requires a build script would affect its parent, then add the key as defaulting to `true` so as to not break backwards-compatibility, then switch the default to be more restrictive over a new edition. (This same key could be used to prevent proc-macros from having arbitrary system access as well, where by default proc macros could be compiled to WASM and run in a WASM sandbox and treated as pure functions.)
I 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…
This was actually the main thing that put me off of Rust. I get the argument for a small std lib. I just also don’t agree it’s worth it. Go seems to handle having a batteries included standard lib just fine.
On the other hand, there are some bad Go standard libraries that are frozen in time.