Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- All those folks telling me to update my dependencies, this is why I don't do it. It's not laziness, it's undeniable foresight.by vatsachak
- 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 binary instead of uploading all your CI secrets and deleting the whole hard drive.
by tancop - Doing software development outside of strict containerization, at the very least, looks increasingly prone to disaster.
Yes, we can argue about the culture of package management (as some of us have with especially npm from day one), but it's done, and your colleagues or AI sidekicks cannot be trusted not to download whatever and try to build and run it. All you can do is limit the effective blast radius.
by fidotron - 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.
by hbbio - 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...
by jakubadamw - Thread on the post from main rust blog: https://news.ycombinator.com/item?id=49372853
Direct post link: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on...
Initial report: https://github.com/rustsec/advisory-db/issues/3161
Other vendor posts:
* https://www.stepsecurity.io/blog/arrayref-rust-crate-supply-...
* https://research.jfrog.com/post/arrayref-proc-macro1-crates-...
* https://www.aikido.dev/blog/two-popular-rust-crates-arrayref...
by ramimac - 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 total.
There’s no reason why this can’t be replicated elsewhere. The key is to make the programming language reasonably robust with at least 80% of common non-UI dev needs built in and put the remaining 20% and UI bits into a small family of well-supported, community-embraced, preferably first party libraries.
That would make it unnecessary to pull in foreign dependencies in the overwhelming majority of projects. What few do get pulled in becomes lightweight, easily verifiable syntactic sugar or libraries with purposes too niche to be worth targeting.
Of course this approach can go wrong too. You could easily end up with a monster like Boost, but that comes down to project administration keeping creep under control and proper modular design.
- 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://web.archive.org/web/20260820145918/https://github.co...
[2]: https://crates.io/crates/arrayref/versions
[3]: https://crates.io/crates/arrayref/security (I'd give an Wayback link but that's also broken https://web.archive.org/web/20260820150747/https://crates.io...)
[4]: https://github.com/rustsec/advisory-db/issues/3161#issuecomm...
by cube00