返回资讯中心
外部精选
软件工程
#开发者实时流

Chainguard 启动 Project Theseus,首个组件 challoc 已开源

来源标题:Project Theseus, Starting with Challoc

Chainguard 宣布启动 Project Theseus,计划以公开方式逐个重建开源核心组件,以消除整类漏洞。首个组件 challoc 是用 Rust 编写的内存分配器,已在 GitHub 上公开。该项目旨在改变依赖人工修补漏洞的现状,从源头减少同类缺陷反复出现。

Hacker News 最新chillax2026/11/14 · 今天30 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

所有文章2026年11月13日 隆重推出 Project Theseus,从 challoc 开始 John Slack John Slack 高级产品经理 + 另外 2 人 今天,我们宣布 Chainguard 的 Project Theseus,这项使命旨在重建开源的核心组件,并消除整类 bug。我们正以公开的方式,一个组件一个组件地推进。第一个组件 challoc 是一个用 Rust 编写的内存分配器,今天已在 GitHub 上公开。

全世界所依赖的开源软件,是在一个不同的时代、针对一种不同的威胁态势构建起来的。它的作者们使用的是当时手头可用的工具。C 语言把内存管理交到了程序员手中,每个项目都各自包含针对诸如转义 shell 命令或验证文件路径之类的检查。这些手写的检查每一个都依赖于程序员把一切都做对,而数十年的细致工作也未能阻止同类 bug 年复一年地出现。

我们知道不能永远只靠打补丁,必须想办法让这台跑步机慢下来。Chainguard 的计划是现在就着手,通过重建开源栈本身的一部分,以消除整类漏洞的方式来做。我们相信这在今天是可以实现的,而且结果可以易于迁移、更快,甚至更有趣。challoc 展示了这一切。

发现 bug 的速度已经远远快于修复 bug 的速度。通过 Project Glasswing,截至 11 月 2 日,Anthropic 已在 680 个开源项目中披露了 5,087 个漏洞。据 Anthropic 所知,其中只有 629 个已被修补。这并不是维护者的失职。AI 全天候地发现 bug,而每一个修复仍然必须由上游编写、审查并发布。

在上游发布修复只是开始。操作系统组件的每一个新版本都必须被某个发行版采纳、构建、发布,然后由用户部署。随着从披露到被利用的时间不断缩短,上述每一步都是攻击者的窗口期。这就是安全所奔跑的那台跑步机,而且它还在不断加速:Chainguard 如今每天发布的修复数量是一年前的七倍。

如果业界想要放慢这一节奏,就必须预防 bug,而不仅仅是打补丁。在广泛使用的正则表达式库 PCRE2 中,其 68 个 CVE 里有 53 个来自同样的几类错误,而现代语言和工具可以排除这类错误。正如我们在《Rebuild the planet》中所说:“你无法靠打补丁摆脱这一困境。”

这就是我们启动 Project Theseus 的原因:重写核心组件,使整类 bug 在其中不可能发生,从而需要修补的 bug 更少。

忒修斯之船是一个古老的思维实验:如果你一块一块地更换一艘船的木板,它还是同一艘船吗?Project Theseus 对开源栈做了类似的事情。它旨在替换那些同类 bug 不断出现的组件,一次一个。

这是一个实验,也是一组公开的代码仓库。每一个仓库都包含一个 Guarded Component,即某个核心开源组件的替代品,其构建方式使整类 bug 不可能发生。有些是我们用 AI agent 构建的重写版本,另一些则是我们采纳并加固的现有重写版本。两者都遵循同样的标准: 由我们所交付的内容塑造。每一个都针对它所替代的组件进行模糊测试。Chainguard 拥有超过 3,000 个生产镜像的目录,以及其背后数以万计的软件包,它们塑造了设计,并充当测试平台。 公开的证据。每个组件的源代码从我们宣布之日起就在 GitHub 上公开,同时还会在其就绪时公布一致性结果和性能对比,以及最关键部分的正式证明。 我们从内存安全、从内存分配器开始 Project Theseus,因为它几乎位于容器中运行的一切之下。challoc 是一个用 Rust 编写的分配器,旨在替代 glibc malloc、jemalloc、tcmalloc 和 mimalloc。它导出了标准 C 函数以及 jemalloc 的扩展 API,因此为 jemalloc 构建的程序无需改动即可在其上运行。 Project Theseus 的大部分都依赖同一种策略:以安全的 Rust 为核心,外面是一层经过审查的 unsafe 外壳。将此应用于分配器,就把这一策略推到了极限,因为它充当着其他一切所依赖的基础 unsafe 层。它的职责是把原始地址转换为供 C 程序使用的内存,而没有任何编译器能检查这一点。因此 challoc 对其 unsafe 代码的要求高于代码审查,其中大部分都经过了证明。这赋予了 challoc 两种安全性: 分配器自身的代码经过证明。Verus 是一个针对 Rust 的正式验证器,它依据书面契约证明了 challoc 86% 的函数和 94% 的代码行,而模型检查器则覆盖了边缘处的系统调用和汇编。这些证明包括:已分配的块永远不会与分配器元数据共享任何一个字节,以及过去 glibc、jemalloc 和 tcmalloc CVE 背后的尺寸溢出 bug 无法在主要入口点上发生。每一个剩余的假设都列在仓库中。 程序中的堆 bug 要难利用得多。challoc 无法让 C 程序变得内存安全,但它拿走了攻击者赖以构建的基础。它不把任何状态保存在你的数据之中或旁边,因此溢出或通过失效指针的写入都无法操纵分配器。尺寸类别位于独立的、随机化的地址范围中,彼此之间有保护区域。challoc 会检查无效释放和双重释放,一旦发现就中止程序,而一个可选启用的设置会让每一项检查都立即执行。 在《Rebuild the planet》中,我们运行了 Chainguard Harness——我们为 Project Glasswing 工作构建的 bug 发现工具——对每个发行版都会提供的五个软件包进行了扫描。它发现了 312 个不同的 bug,其中许多是内存安全 bug。在底下有 challoc 的情况下,其中近三分之一会安全地失败,而不是把控制权交给攻击者。

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →