Rust 恶意包 arrayref 在编译时植入载荷

我认为我们在语言和库的设计上应该采取更“开箱即用（batteries included）”的路线。我们陷入这种混乱的全部原因，就是大家觉得标准库（stdlibs）越精简越好，甚至认为这是可取的，结果导致基础语言几乎没法用。

我完全可以轻松构建出功能强大、体验良好的 Apple 平台应用，顶级依赖不超过 5 个。在很多情况下，我总共只用 0 到 2 个依赖。

这完全可以在其他地方复制。关键在于让编程语言足够健壮，内置至少 80% 的常见非 UI 开发需求，剩下的 20% 和 UI 部分则交给一小系列支持良好、社区认可、最好是官方的一级库。

这样一来，绝大多数项目就无需引入外部依赖了。那些少数确实需要引入的，也就变成了轻量级的、易于验证的语法糖，或是用途过于小众而不值得成为攻击目标的库。

当然，这种做法也可能走偏。你很容易搞出一个像 Boost 那样的庞然大物，但这归根结底取决于项目治理能否控制住功能蔓延（creep），以及是否采用了恰当的模块化设计。

Rust 官方博客帖子的讨论串：https://news.ycombinator.com/item?id=49372853

帖子直达链接：https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on...

初始报告：https://github.com/rustsec/advisory-db/issues/3161

其他厂商的帖子：

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

Cargo 迫切需要为 build.rs 脚本提供沙箱隔离。之前尝试过，但没太大进展¹。

¹ https://rust-lang.github.io/goals/2024h2/sandboxed-build-scr...

Rust 遭受了与 JS 生态同样的弊病。任何重要的 crate 都会引入数百甚至数千个依赖。其中某个作者遭到 AI 辅助攻击的概率实在太高了。

此外，这些依赖中的大多数提供的功能广度，最终包其实根本不需要。

如果不至少在严格的容器化环境中进行软件开发，看起来越来越容易遭遇灾难。

是的，我们可以争论包管理的文化（就像我们中有些人从一开始就对 npm 所争论的那样），但事情已经发生了，而且你不能指望你的同事或 AI 助手不会下载任何东西并尝试构建运行它。你唯一能做的就是限制有效的爆炸半径（blast radius）。

所有那些让我更新依赖的家伙，这就是我不更新的原因。这不是懒惰，这是无可辩驳的远见。

我们现在需要基于效应（effect-based）的语言。这是唯一能在编译前就保证策略（如禁止网络、禁止文件访问、禁止 unsafe 代码或 FFI）的方法。如果有 Epic 的人在听，请给我们一个开源 Verse 编译器的时间表。

在此之前，我觉得可以魔改 Cargo，让所有构建脚本都在微虚拟机（microVM）中运行。这样爆炸半径就会被限制在二进制文件中的恶意代码，而不是上传你所有的 CI 密钥或删除整个硬盘。

几个月前，当几次供应链攻击击中 npm 生态时，我构建了 SBE：https://github.com/tyrchen/sbe。

它利用 macOS 上的 Seatbelt / SBPL 以及 Linux 上的 Landlock LSM + seccomp-bpf 为任意 CLI 命令提供沙箱隔离。你可以用它来保护本地依赖构建，或者将其集成到 GitHub Actions 中，为 CI 增加一层保护。

欢迎试用——我很乐意听到你们的反馈。

这是一个开发者环境蠕虫，问题在于终端没有数据隔离。

你的开发工具不应该能够访问你的密钥。

我已经在 nixos 上构建了一个提供数据隔离的模型：

https://decentstat.es/posts/shai-halud-nix-housing/

（非 vibe coded）