Rust 的 WebAssembly 目标即将发生一项变更，此变更可能破坏现有项目，本文旨在通知用户即将到来的变化、解释其内容以及处理方法。具体而言，Rust 中所有 WebAssembly 目标此前均使用 --allow-undefined 标志链接至 wasm-ld，而该标志现将被移除。

什么是 --allow-undefined？

目前 Rust 中的 WebAssembly 二进制文件均通过 wasm-ld 链接生成。其作用类似于 ld、lld 和 mold 等工具；它接收独立编译的 crate/对象文件并生成最终的二进制文件。自 Rust 引入 WebAssembly 目标以来，--allow-undefined 标志一直被传递给 wasm-ld。该标志的文档说明如下：

  --allow-undefined       Allow undefined symbols in linked binary. This options
                          is equivalent to --import-undefined and
                          --unresolved-symbols=ignore-all

此处的“未定义”特指 wasm-ld 本身中的符号解析。符号的概念与原生平台紧密对应，例如所有 Rust 函数都有关联的符号。符号在 Rust 中可通过 extern "C" 块引用，例如：

unsafe extern "C" {
    fn mylibrary_init();
}

fn init() {
    unsafe {
        mylibrary_init();
    }
}

符号 mylibrary_init 是一个未定义符号。它通常由程序的另一个组件（如外部编译的 C 库）定义，该组件将提供此符号的定义。然而，通过向 wasm-ld 传递 --allow-undefined，上述代码将生成如下 WebAssembly 模块：

(module
    (import "env" "mylibrary_init" (func $mylibrary_init))

    ;; ...
)

这意味着未定义符号被忽略，并最终作为导入符号出现在生成的 WebAssembly 模块中。

确切的历史细节已难考究，但目前普遍认为在 Rust 工具链中引入 wasm-ld 的早期阶段，--allow-undefined 实际上是必需的。这个历史遗留的解决方法一直沿用至今，未曾改变。

--allow-undefined 有何不妥？

在所有 WebAssembly 目标上使用 --allow-undefined，使得 rustc 在 WebAssembly 与其他平台之间引入了行为差异。--allow-undefined 的主要风险在于，构建过程中的错误配置或失误可能导致生成损坏的 WebAssembly 模块，而非产生编译错误。这意味着问题被延迟发现，拉长了从问题引入到发现之间的距离。一些典型问题场景包括：

• 如果将 mylibrary_init 误写为 mylibraryinit，最终二进制文件将导入 mylibraryinit 符号，而非调用链接的 C 符号 mylibrary_init。

• 如果 mylibrary 被错误地未编译并链接到最终应用程序中，mylibrary_init 符号将被导入，而不是产生“未定义”的链接器错误。

• 如果使用外部工具（如 wasm-bindgen 或 wasm-tools component new）处理 WebAssembly 模块，这些工具默认不知道如何处理 "env" 导入，很可能会产生某种错误信息，且该信息通常无法清晰关联到原始代码及其导入来源。

• 对于 Web 用户，如果你曾遇到类似 Uncaught TypeError: Failed to resolve module specifier "env". Relative references must start with either "/", "./", or "../". 的错误，这可能意味着 "env" 意外泄漏到最终模块中，而真正的错误是未定义符号错误，而非缺少提供的 "env" 项。

所有原生平台默认将未定义符号视为错误，因此通过使用 --allow-undefined，rustc 在 WebAssembly 目标上引入了令人意外的行为。此次变更的目标正是移除这种意外，使其行为更接近原生平台。

哪些内容会中断，以及如何修复？

理论上，此变更不会导致大量中断。如果最终的 WebAssembly 二进制文件导入了意外符号，那么该二进制文件很可能无法在所需的嵌入环境中运行，因为所需的嵌入环境可能未提供该符号的定义。例如，如果你为 wasm32-wasip1 编译应用程序，最终二进制文件导入 mylibrary_init 将导致在大多数运行时中失败运行，因为它被视为未解析的导入。这意味着在大多数情况下，此变更不会破坏用户，而是会提供更好的诊断信息。

然而，本文的原因在于用户可能有意依赖此行为。例如，你的应用程序可能包含：

unsafe extern "C" {
    fn js_log(n: u32);
}

// ...

然后可能是一些如下所示的 JavaScript 代码：

let instance = await WebAssembly.instantiate(module, {
    env: {
        js_log: n => console.log(n),
    }
});

实际上，用户可能明确依赖 --allow-undefined 在最终 WebAssembly 二进制文件中生成导入的行为。

如果遇到这种情况，可以通过 #[link] 属性显式指定 wasm_import_module 名称来修复代码：

#[link(wasm_import_module = "env")]
unsafe extern "C" {
    fn js_log(n: u32);
}

// ...

这将保持与之前相同的行为，并且将不再被视为 wasm-ld 的未定义符号，并且在此次变更前后均可正常工作。

受影响的用户也可以使用 -Clink-arg=--allow-undefined 进行编译，以快速恢复旧行为。

此变更何时生效？

移除 wasm 目标上的 --allow-undefined 正在通过 rust-lang/rust#149868 进行。该变更计划不久后进入 nightly 版本，并将随 Rust 1.96 于 2026-05-28 发布。如果你因此次变更引发任何问题，请随时在 rust-lang/rust 上提交 issue。

由 mimo-v2.5 模型翻译，花费 7395 tokens

默认情况下构建更少的目标

在2026年5月1日，docs.rs将对其构建行为进行一项破坏性变更。

目前，如果一个crate的docs.rs元数据中没有定义targets列表，docs.rs将为默认的五个目标构建文档。

从2026年5月1日开始，docs.rs将只为默认目标构建文档，除非明确请求其他目标。

这是我们自2020年引入的一项变更中的下一步，当时docs.rs添加了选择更少构建目标的支持。大多数crate不会为不同目标编译不同的代码，因此默认构建更少的目标更适合大多数发布。这也可以减少构建时间并节省docs.rs的资源。

此变更仅影响：

1. 新发布
2. 旧发布的重新构建

默认目标如何选择？

如果你没有设置default-target，docs.rs将使用其构建服务器的目标：x86_64-unknown-linux-gnu。

你可以通过在docs.rs元数据中设置default-target来覆盖它：

[package.metadata.docs.rs]
default-target = "x86_64-apple-darwin"

我如何为额外的目标构建文档？

如果你的crate需要为默认目标以外的目标构建文档，请在Cargo.toml中明确完整定义列表：

[package.metadata.docs.rs]
targets = [
    "x86_64-unknown-linux-gnu",
    "x86_64-apple-darwin",
    "x86_64-pc-windows-msvc",
    "i686-unknown-linux-gnu",
    "i686-pc-windows-msvc"
]

设置targets后，docs.rs将仅为这些目标构建文档。

docs.rs仍然支持Rust工具链中可用的任何目标。只有默认行为正在改变。

由 mimo-v2.5 模型翻译，花费 2858 tokens

Rust 团队很高兴地宣布推出新版本的 Rust，1.95.0。Rust 是一种赋能每个人构建可靠、高效软件的编程语言。

如果你已经通过 rustup 安装了先前版本的 Rust，你可以通过以下方式获取 1.95.0：

$ rustup update stable

如果你尚未安装，可以从我们网站的相关页面获取 rustup，并查看 1.95.0 的详细发布说明。

如果你想通过测试未来的版本来帮助我们，你可以考虑在本地更新以使用 beta 频道（rustup default beta）或 nightly 频道（rustup default nightly）。请报告你可能遇到的任何错误！

1.95.0 稳定版包含哪些内容

cfg_select!

Rust 1.95 引入了 cfg_select! 宏，其作用大致类似于在 cfg 上进行编译时的 match。这 与流行的 cfg-if crate 实现了相同的目的，尽管语法不同。cfg_select! 会展开为第一个配置谓词求值结果为 true 的分支的右侧部分。一些示例：

cfg_select! {
    unix => {
        fn foo() { /* unix 特定功能 */ }
    }
    target_pointer_width = "32" => {
        fn foo() { /* 非 unix、32 位功能 */ }
    }
    _ => {
        fn foo() { /* 回退实现 */ }
    }
}

let is_windows_str = cfg_select! {
    windows => "windows",
    _ => "非 windows",
};

匹配表达式中的 if-let 守卫

Rust 1.88 稳定了 let 链。Rust 1.95 将该能力引入到 match 表达式中，允许基于模式匹配进行条件判断。

match value {
Some(x) if let Ok(y) = compute(x) => {
        // `x` 和 `y` 都可以在这里使用
        println!("{}, {}", x, y);
    }
_ => {}
}

请注意，目前编译器不会将 if let 守卫中匹配的模式视为整个匹配详尽性评估的一部分，这与 if 守卫的行为一致。

已稳定的 API

• MaybeUninit<[T; N]>: From<[MaybeUninit<T>; N]>
• MaybeUninit<[T; N]>: AsRef<[MaybeUninit<T>; N]>
• MaybeUninit<[T; N]>: AsRef<[MaybeUninit<T>]>
• MaybeUninit<[T; N]>: AsMut<[MaybeUninit<T>; N]>
• MaybeUninit<[T; N]>: AsMut<[MaybeUninit<T>]>
• [MaybeUninit<T>; N]: From<MaybeUninit<[T; N]>>
• Cell<[T; N]>: AsRef<[Cell<T>; N]>
• Cell<[T; N]>: AsRef<[Cell<T>]>
• Cell<[T]>: AsRef<[Cell<T>]>
• bool: TryFrom<{integer}>
• AtomicPtr::update
• AtomicPtr::try_update
• AtomicBool::update
• AtomicBool::try_update
• AtomicIn::update
• AtomicIn::try_update
• AtomicUn::update
• AtomicUn::try_update
• cfg_select!
• mod core::range
• core::range::RangeInclusive
• core::range::RangeInclusiveIter
• core::hint::cold_path
• <*const T>::as_ref_unchecked
• <*mut T>::as_ref_unchecked
• <*mut T>::as_mut_unchecked
• Vec::push_mut
• Vec::insert_mut
• VecDeque::push_front_mut
• VecDeque::push_back_mut
• VecDeque::insert_mut
• LinkedList::push_front_mut
• LinkedList::push_back_mut
• Layout::dangling_ptr
• Layout::repeat
• Layout::repeat_packed
• Layout::extend_packed

以下之前已稳定的 API 现在在 const 上下文中也已稳定：

• fmt::from_fn
• ControlFlow::is_break
• ControlFlow::is_continue

取消 JSON 目标规范的稳定支持

Rust 1.95 在稳定版中移除了向 rustc 传递自定义目标规范的支持。这应该不会影响任何使用完全稳定工具链的 Rust 用户，因为构建标准库（包括仅 core）已经需要使用仅限 nightly 的特性。

我们也在 跟踪问题上收集自定义目标的用例，同时我们也在考虑是否应该最终以某种形式稳定此特性。

其他变更

请查看 Rust、Cargo 和 Clippy 的所有变更。

1.95.0 的贡献者们

许多人共同参与创建了 Rust 1.95.0。没有你们所有人，我们无法完成它。谢谢！

由 mimo-v2.5 模型翻译，花费 10536 tokens

正如先前所宣布的，Rust项目将参加Google Summer of Code (GSoC) 2026。GSoC是由Google组织的一项全球性计划，旨在为开源世界引入新的贡献者。

几个月前，我们发布了一份GSoC项目创意列表，并开始在我们的Zulip频道上与潜在的GSoC申请者讨论这些项目。我们与潜在贡献者进行了许多有趣的讨论，甚至看到其中一些人在GSoC正式开始之前就对各种Rust项目仓库做出了重要的贡献！

申请者在3月底前准备并提交了他们的项目提案。今年，我们收到了96份提案，比去年增加了50%。我们很高兴再次有这么多人对我们的项目感兴趣！与今年许多其他GSoC组织一样，我们在处理一些AI生成的提案和使用AI代理生成的低质量贡献时有些挣扎，但这还在可控范围内。

GSoC要求我们提供一份按优先级排序的最佳提案列表，这总是具有挑战性的，因为Rust是一个拥有众多优先事项的大型项目。我们的导师审查了提交的提案，并根据他们与特定申请者之前的互动、其目前的贡献、提案本身的质量，以及所提项目对Rust项目及其更广泛社区的重要性进行了评估。我们还必须考虑导师的时间和可用性。不幸的是，由于过去几周有几位导师失去了Rust工作的资助，我们不得不取消一些项目。

与GSoC通常的情况一样，即使一些项目主题收到了多份提案¹，我们也只能为每个项目主题选择一份提案。我们还必须在针对不同工作的提案之间做出选择，以避免让单个导师因承担多个项目而不堪重负。最终，我们将列表缩减至那些我们现有的导师团队仍然能够实际支持的最佳提案。我们提交了这份名单，并热切地等待着其中有多少提案能被GSoC接受。

入选项目

4月30日，Google公布了入选的项目。我们很高兴地分享，Google为Google Summer of Code 2026接受了13个Rust项目的提案。这是很多项目！我们对GSoC 2026感到非常高兴和兴奋！

以下是入选提案的列表（按字母顺序排列），包括其作者和指定的导师：

• 为Rust实现安全GPU卸载的前端，由Marcelo Domínguez提交，导师为Manuel Drehwald
• 为Wild添加WebAssembly链接支持，由Kei Akiyama提交，导师为David Lattimore
• 将自动微分和卸载引入Rust CI，由Shota Sugano提交，导师为Manuel Drehwald
• 为Miri实现调试器，由Mohamed Ali Mohamed提交，导师为Oli Scherer
• 实现impl和mut限制，由Ryosuke Yamano提交，导师为Jacob Pratt和Urgau
• 改善serialport-rs的易用性和安全性，由Tanmay提交，导师为Christian Meusel
• libc：过渡不同位宽的时间和偏移变体，并弃用易出错的常量，由Adam Martinez提交，导师为Trevor Gross
• 使用Wild链接Linux内核及其模块，由Vishruth Thimmaiah提交，导师为David Lattimore
• 将rust-analyzer辅助功能迁移到SyntaxEditor，由Shourya Sharma提交，导师为Chayim Refael Friedman和Lukas Wirth
• 将std::arch测试套件移植到rust-lang/rust，由Sumit Kumar提交，导师为Jakub Beránek和Folkert de Vries
• 重组tests/ui/issues，由zedddie提交，导师为Teapot和Kivooeo
• 利用调试器API改进调试信息测试的准确性和错误报告，由Anthony Bolden提交，导师为Jakub Beránek和Jieyou Xu
• 为rustup提供XDG路径支持，由Guicheng Liu提交，导师为rami3l

祝贺所有提案被选中的申请者！我们的导师期待与你们合作，共同推进这些令人兴奋的项目，以改善Rust生态系统。你们应该很快就会收到我们的消息，以便我们开始协调你们的GSoC项目工作。

我们很高兴能指导三位去年已经与我们合作过GSoC的贡献者。欢迎回来，Kei、Marcelo和Shourya！

我们要感谢所有提案未被接受的申请者，感谢你们与Rust社区的互动以及对各种Rust项目的贡献。有一些很棒的提案未能入选，很大程度上是因为导师资源有限。然而，即使你的提案未被接受，如果你愿意在GSoC之外继续为你感兴趣的项目做出贡献，我们会非常高兴！我们的项目创意列表仍然有效，可以作为希望参与有助于Rust项目和Rust生态系统项目的贡献者的通用入口点。一些Rust项目目标也正在寻求帮助。

很有可能我们明年还会参加GSoC（尽管目前还不能保证），所以我们希望将来能再次收到你们的提案！

入选的GSoC项目将持续数月。在2026年GSoC结束后（2026年秋季），我们将发布一篇博文，总结入选项目的成果。

1. 最受欢迎的项目主题收到了十四份不同的提案！↩

由 mimo-v2.5 模型翻译，花费 5581 tokens

nvptx64-nvidia-cuda 编译目标用于 NVIDIA GPU。使用此目标时，最终输出为 PTX。两种版本选择决定了该输出：

• GPU 架构（例如 sm_70、sm_80 等），它决定了哪些 GPU 可以运行 PTX，以及
• PTX ISA 版本，它决定了哪些 CUDA 驱动程序版本可以加载（并即时编译）PTX。

在 Rust 1.97（计划于 2026 年 7 月 9 日发布）中，nvptx64-nvidia-cuda 的基准 PTX ISA 版本和 GPU 架构将会提高。这些更改影响了 Rust 编译器（rustc）及相关主机工具，并且使得无法生成与旧版 GPU 和旧版 CUDA 驱动程序兼容的 PTX 产物。

新的最低支持版本将是：

• PTX ISA 7.0（需要 CUDA 11 或更高版本的驱动程序）
• SM 7.0（计算能力低于 7.0 的 GPU 不再受支持）

为何更改要求？

在此之前，Rust 一直支持为广泛的 GPU 架构和 PTX ISA 版本生成 PTX。实际上，存在一些缺陷可能导致有效的 Rust 代码引发编译器崩溃或错误编译。提高基线要求可以解决这些问题，并为剩余受支持的硬件提供更完善的支持。

移除支持会影响使用被移除架构的用户。在这种情况下，最近受影响的 GPU 架构可追溯至 2017 年，并且已不再受到 NVIDIA 的积极支持。因此，我们预计这一变更的整体影响有限。

维护对这些架构的支持需要大量投入。这些移除使我们能够集中开发精力，改善当前受支持硬件的正确性和性能。

升级到 Rust 1.97 后会发生什么？

如果您需要目标 CUDA 驱动程序不支持 PTX ISA 7.0（即 CUDA 10 时代及更早的驱动程序），Rust 1.97 将无法再生成与该环境兼容的 PTX。同样，如果您需要在计算能力低于 7.0 的 GPU（例如 Maxwell 或 Pascal）上运行，Rust 1.97 也将无法为这些 GPU 生成兼容的 PTX。

假设您的目标是与 CUDA 11 或更高版本兼容的 CUDA 驱动程序，并使用计算能力 7.0 或更高的 GPU：

• 如果您未指定 -C target-cpu，新的默认值将是 sm_70，您的构建应继续正常工作（但将不再兼容 Volta 之前的 GPU）。
• 如果您当前指定了较旧的 -C target-cpu（例如 sm_60），您需要要么：
  • 移除该标志，让其默认为 sm_70，要么
  • 将其更新为 sm_70 或更新的架构。
• 如果您已经指定了 -C target-cpu=sm_70（或更新），此次更新不应带来行为变化。

有关构建和配置 nvptx64-nvidia-cuda 的更多详细信息，请参阅平台支持文档。

由 mimo-v2.5 模型翻译，花费 2634 tokens

Rust 项目在参与各类开源导师计划方面已有良好记录，包括连续三年（含今年）的 Google Summer of Code，以及此前的 OSPP 计划。我们很高兴地宣布，今年 Rust 项目还将参与从2026年5月开始的 Outreachy 计划。

每个导师计划根据其目标群体和计划宗旨有不同的参与资格标准。Outreachy 为来自任何背景、在所处技术行业中面临代表性不足、系统性偏见或歧视的人士提供开源实习机会。您可以在 Outreachy 官网 了解更多计划详情。

Outreachy 与 Google Summer of Code 的异同

Outreachy 在某些方面与 Google Summer of Code（GSoC）相似，但也存在差异。首先，与 GSoC 不同，Outreachy 实习生需先申请整个计划，然后才能申请特定社区。其次，虽然 GSoC 申请者通常在申请前提交各种贡献，但 Outreachy 有一个专门的贡献期，贡献不仅可选，而且是必需的。最后，Outreachy 申请者提交的申请材料与 GSoC 类似，社区根据这些申请和实习生的贡献来选拔实习生。Outreachy 每年有两个实习期：一个从5月到8月（我们目前参与的这一期），另一个从12月到次年3月。

Google Summer of Code 与 Outreachy 的另一个主要区别是实习生津贴的来源。GSoC 由 Google 慷慨承担贡献者津贴和管理费用，而 Outreachy 则由社区承担实习生的津贴和管理费用。

我们将为2026年5月批次指导4名实习生

由于资金和指导能力有限，Rust 项目决定选择四名实习生进行指导。以下将简要介绍这些项目。

从 Rust 调用重载的 C++ 函数

Ajay Singh 已被选中，由 teor、Taylor Cramer 和 Ethan Smith 指导。

该项目旨在实现实验性功能，以从 Rust 调用重载的 C++ 函数，并开始在一些代表性用例中测试该功能。

大规模的 Rust 编译器代码覆盖率分析

Akintewe Oluwasola 已被选中，由 Jack Huey 指导。

该项目旨在开发工作流程，以在整个编译器测试套件和通过 Crater 检测到的生态系统 crate 规模上运行和分析编译器的代码覆盖率。希望能够检测到编译器内部以及生态系统中测试不足的情况，并构建工具对此进行持续分析。

对 a-mir-formality 类型系统实现进行模糊测试

Tunde-Ajayi Olamiposi 已被选中，由 Niko Matsakis、Rémy Rakic 和 tiif 指导。

该项目旨在为 a-mir-formality（一个正在进行中的 Rust 类型和 trait 系统模型）实现模糊测试。目标是生成程序，以识别 a-mir-formality 中语义定义不足的规则。

提升 Rust 项目 GitHub Actions 的安全性

oghenerukevwe Sandra Idjighere 已被选中，由 Marco Ieni 和 Ubiratan Soares 指导。

该项目旨在提升 Rust 项目所属仓库的 GitHub Actions 工作流的安全性。它将开发工具和工作流，集成现有软件，以分析 GitHub 仓库并检测其是否遵循最佳安全实践、修复现有问题，并确保未来遵循良好的安全实践。

下一步计划

在未来3个月里，实习生们将与他们的导师密切合作，在各自项目上取得进展。实习期结束后，我们将撰写另一篇博文分享成果！届时再见！

我们也要感谢所有提交申请并做出贡献的人。选择哪些申请者相当困难。希望将来能再次参与 Outreachy 计划，也期待有其他参与机会。我们非常欢迎留下来并继续参与——Rust 项目中有大量参与机会。

由 mimo-v2.5 模型翻译，花费 3636 tokens

Rust 安全响应团队收到通知，Cargo 在使用稀疏索引协议时，错误地对第三方注册表的 URL 进行了规范化处理。如果托管提供商允许在同一域内以任意名称托管多个注册表，那么能够在某个注册表中发布 crate 的攻击者，就有可能获取同一注册表中其他用户的凭证。

此漏洞被追踪为 CVE-2026-5222。鉴于实施攻击所需条件极其苛刻，该漏洞的严重性为低。

概述

最初，Cargo 仅支持将注册表的索引存储在 git 仓库中。大多数 git 托管方案允许无论是否带有 .git 后缀来访问 git 仓库，因此 Cargo 在规范化注册表 URL 时也反映了这种行为。这使得 https://example.com/index 的凭证可以用于 https://example.com/index.git。

这种规范化被无意中应用到了新的稀疏索引上。稀疏索引可以托管在任何 HTTPS 服务器上，而这些服务器会将带有 .git 后缀的 URL 视为与不带后缀的 URL 不同。

如果满足以下条件：

• https://example.com/index 是一个稀疏索引。
• https://example.com/index 允许 crate 依赖来自任何其他注册表的 crate。
• 攻击者能够在 https://example.com/index 上发布 crate。
• 攻击者能够向 https://example.com/index.git 上传任意文件。

……攻击者可以配置 https://example.com/index.git 成为一个需要身份验证才能下载的 Cargo 稀疏注册表，并且其下载 URL 指向一个能记录所有凭证的服务器。

当攻击者随后在 https://example.com/index 上发布一个依赖于来自 https://example.com/index.git 的 crate bar 的 crate foo，并诱骗受害者下载 foo 时，Cargo 会认为这两个注册表共享相同的凭证，并将受害者的 Cargo 令牌发送给恶意注册表。

缓解措施

将于 2026 年 5 月 28 日发布的 Rust 1.96 版本将更新 Cargo，使其仅从使用 git 协议的注册表 URL 中去除 .git 后缀。对于旧版本 Cargo 的用户，没有可用的缓解措施。

受影响的版本

在 Rust 1.68（稀疏注册表稳定化）至 1.96 之间发布的所有 Cargo 版本均受影响。

致谢

我们要感谢 Christos Papakonstantinou 根据 Rust 安全策略向我们报告此问题。

我们还要感谢帮助我们处理此漏洞的 Rust 项目成员：Arlo Siemens 开发了修复；Weihang Lo、Eric Huss 和 Emily Albini 审核了修复；Emily Albini 撰写了本公告；Emily Albini、Josh Stone 和 Manish Goregaokar 协调了披露工作。

由 mimo-v2.5 模型翻译，花费 2195 tokens

Rust 安全响应团队获悉，Cargo 在处理从第三方注册中心下载的 crate tarball 中的符号链接时存在错误处理，这允许恶意 crate 覆盖同一注册中心中其他 crate 的源代码。

此漏洞被追踪为 CVE-2026-5223。对于第三方注册中心的用户，该漏洞的严重性为中等。crates.io 的用户不受影响，因为 crates.io 禁止上传包含任何符号链接的 crate。

概述

构建 crate 时，Cargo 将其源代码提取到本地缓存（存储在 ~/.cargo 中）中，并为未来的构建重用。Cargo 包含保护措施，以防止任何文件被提取到 crate 自身的缓存目录之外。

经发现，可以制作一个恶意 tarball，它能将文件提取到 crate 自身缓存目录的下一级。根据缓存的结构方式，这允许恶意 crate 覆盖属于同一注册中心的其他 crate 的缓存。

缓解措施

计划于 2026 年 5 月 28 日发布的 Rust 1.96.0 将更新 Cargo，拒绝解压 crate tarball 中的任何符号链接，无论它们来自 crates.io（已经禁止）还是第三方注册中心。请注意，Cargo 在运行 cargo package 或 cargo publish 时从未添加过符号链接，因此这的影响应该很小。

建议无法升级到最新 Rust 版本的用户审核其注册中心中是否存在任何符号链接，并配置其注册中心以拒绝符号链接（如果该选项可用）。

受影响的版本

所有在 Rust 1.96.0 之前发布的 Cargo 版本均受影响。

致谢

我们感谢 Christos Papakonstantinou 根据 Rust 安全策略 向我们报告此问题。

我们还要感谢帮助我们处理此漏洞的 Rust 项目成员：Josh Triplett 开发了修复方案；Arlo Siemsen 审阅了修复方案；Emily Albini 撰写了此公告；Emily Albini、Josh Stone 和 Manish Goregaokar 协调了披露；Ed Page 和 Eric Huss 在披露过程中提供了建议。

由 mimo-v2.5 模型翻译，花费 1761 tokens

Rust 团队很高兴地宣布 Rust 的新版本 1.96.0。Rust 是一种编程语言，赋能每个人构建可靠且高效的软件。

如果您已通过 rustup 安装了以前的 Rust 版本，可以通过以下方式获取 1.96.0：

$ rustup update stable

如果您还没有安装，可以从我们网站的相应页面获取 rustup，并查看1.96.0 的详细发布说明。

如果您想通过测试未来版本来帮助我们，可以考虑在本地更新到使用 beta 通道（rustup default beta）或 nightly 通道（rustup default nightly）。请报告您可能遇到的任何错误！

1.96.0 稳定版中的内容

新的 Range* 类型

许多用户期望 Range 和相关的 core::ops 类型是 Copy 的，但事实并非如此：它们直接实现 Iterator，而在同一类型上同时实现 Iterator 和 Copy 是一个陷阱，因此已避免这样做。RFC3550 提出了一组替代范围类型，这些类型实现 IntoIterator 而非 Iterator，这意味着它们也可以是 Copy 的。该 RFC 的标准库部分现已稳定，引入了：

• core::range::Range
• core::range::RangeFrom
• core::range::RangeInclusive
• 关联迭代器

在不久的将来，Rust 版本还将添加 core::range::RangeFull 和 core::range::RangeTo 作为从 core::ops 的重导出（这些不实现 Iterator 并且已经实现 Copy），以及 core::range::legacy::* 作为当前范围的新位置。像 0..1 这样的范围语法目前仍产生传统类型，但将在未来版本中更新为 core::range 类型。

随着这些稳定化，现在可以在 Copy 类型中存储切片访问器，而无需拆分 start 和 end：

use core::range::Range;

#[derive(Clone, Copy)]
pub struct Span(Range<usize>);

impl Span {
    pub fn of(self, s: &str) -> &str {
        &s[self.0]
    }
}

新的 RangeInclusive 还使其字段公开，而不像传统版本避免暴露耗尽的迭代器状态。对于新类型，这不是问题，因为它必须转换才能开始迭代。

库作者应考虑在公共 API 中使用 impl RangeBounds，它接受传统和新的范围类型。如果需要具体类型，请优先使用新范围，因为这最终将成为默认值。

断言匹配模式

新的宏 assert_matches! 和 debug_assert_matches! 检查值是否匹配给定模式，否则使用值的 Debug 表示进行 panic。这些本质上与 assert!(matches!(..)) 和 debug_assert!(matches!(..)) 相同，但打印的值提高了诊断失败的可能性。

这些新宏未添加到标准预导入中，因为它们会与提供同名宏的流行第三方 crate 冲突。相反，应在使用前从 core 或 std 手动导入。

use core::assert_matches;

/// [Random Number](https://xkcd.com/221/)
fn get_random_number() -> u32 {
    // chosen by a fair dice roll.
    // guaranteed to be random.
    4
}

fn main() {
    assert_matches!(get_random_number(), 1..= 6);
}

WebAssembly 目标的更改

WebAssembly 目标不再向链接器传递 --allow-undefined，这意味着链接时的未定义符号现在会导致链接器错误，而不是被转换为来自 "env" 模块的 WebAssembly 导入。此更改防止模块链接，除非所有链接相关符号都已定义，以便更早地捕获错误并防止符号命名或类似问题的意外问题。

未定义的链接相关符号通常表明与构建时间相关的错误或错误配置。但是，如果旧行为是预期的，则可以通过 RUSTFLAGS=-Clink-arg=--allow-undefined 或通过编辑源代码并在定义符号的块上使用 #[link(wasm_import_module = "env")] 来重新启用。

此更改已在本博客中先前宣布，现在在 Rust 1.96 中生效。

稳定化的 API

• assert_matches!
• debug_assert_matches!
• From<T> for AssertUnwindSafe<T>
• From<T> for LazyCell<T, F>
• From<T> for LazyLock<T, F>
• core::range::RangeToInclusive
• core::range::RangeFrom
• core::range::RangeFromIter
• core::range::Range
• core::range::RangeIter

两个 Cargo 公告

Rust 1.96 包含针对第三方注册表用户的两个漏洞修复。

• CVE-2026-5223 是一个中等严重性漏洞，涉及使用符号链接提取 crate 压缩包。

• CVE-2026-5222 是一个低严重性漏洞，涉及使用规范化 URL 进行身份验证。

crates.io 用户不受任何漏洞影响。

其他更改

查看 Rust、Cargo 和 Clippy 中的所有更改。

1.96.0 的贡献者

许多人共同创建了 Rust 1.96.0。没有你们，我们无法完成。谢谢！

由 mimo-v2.5 模型翻译，花费 8481 tokens

如果您希望在经济上支持 Rust 的开发，请考虑捐赠给 Rust 基金会维护者基金。

几个月前，Rust 基金会宣布了Rust 基金会维护者基金（RFMF）。自那时起，Rust 项目一直与 Rust 基金会密切合作，以确定该基金将如何具体用于支持 Rust 维护者。这促成了RFC #3931 的接受，该 RFC 建立了资金团队以及驻场维护者计划。

资金团队的主要目标是确保从事 Rust 及其工具链工作的维护者得到适当的支持。我们将与 Rust 项目成员交谈，了解他们的资金状况；与 Rust 团队负责人会面，了解他们的维护需求；接触公司，寻找他们通过支持 Rust 维护者来投资 Rust 的机会；协调各种资金筹措工作，并确保在内容团队的帮助下，资助维护工作的积极影响得到显著宣传。

驻场维护者是一项新的计划，旨在为现有的 Rust 项目维护者提供经济支持¹。每位驻场维护者将获得资金以维护 Rust 的一个或多个关键部分，例如编译器、标准库、Cargo、Clippy 或 Rust 项目开发和维护的众多其他项目之一。资助的工作将包括执行大规模重构、代码审查、为新功能解除阻碍、问题分类、指导其他贡献者等活动，并将根据其支持团队的指导优先级与他们自身在项目内选择的优先级进行分配。在适用的情况下，也鼓励驻场维护者提出、倡导并推动Rust 项目目标。

该计划的目标是提供稳定且长期的资金支持，使维护者能够专注于确保 Rust 长期健康的重要工作。资金团队将根据资金可用性和 Rust 项目内的维护需求来选择驻场维护者，并帮助确保他们取得成功。我们预计这通常是一个（接近）全职的职位，但这将取决于工作性质和维护领域。

该计划扩展了我们对 Rust 维护者的现有支持，例如项目管理计划和编译器运维计划。一个重要的发展是，我们现在有一个集中的机制来收集个人和公司的捐款，以及一个专门的团队来帮助将这些资金定向分配给特定的维护者。您可以在RFC中找到有关资金团队和驻场维护者计划的更多详细信息。

我们预计将在未来几个月内聘请第一位驻场维护者，并在此博客上宣布，敬请期待！

如何贡献资金

如果您是希望帮助 Rust 取得成功并蓬勃发展的个人，您可以通过GitHub Sponsors²向 RFMF 捐款。希望投资于 Rust 更好维护的公司也可以通过 GitHub Sponsors 捐款，或直接联系 Rust 基金会。

重要的是，该基金的所有收益将直接用于支持 Rust 项目维护者。我们目前预计这主要通过驻场维护者计划实现，但也可以根据资金团队的决定，以小额赠款或其他机制的形式进行。我们将在过程中弄清楚这一点，因为这对我们来说也是相当新的。

我们非常感谢每一笔捐款，无论金额多小，因为有了更多的资金，我们可以聘请更多的维护者，以确保我们能够继续开发 Rust，并且重要的改进不会被维护任务所阻碍。这一点在当前尤为重要，因为 Rust 在工业界的各种应用领域正开始被越来越广泛地采用，这增加了对持续维护的需求。多种资金来源的重要性因我们目前观察到的一个不幸趋势而更加凸显：关键 Rust 维护者因预算调整而失去了其 Rust 工作的资金。Rust 基金会维护者基金旨在为 Rust 维护者提供稳定的资金支持，使其较少依赖于就业市场和 IT 行业的突然变化。

与大多数事情一样，没有一种万能的解决方案，因此有多种方式可以在经济上支持 Rust。RustNL 维护者团队最近聘请了几位 Rust 项目维护者。此前，我们撰文介绍了您可以如何支持从事 Rust 工作的特定个人。还有一些正在寻求资金的 Rust 项目目标。我们欢迎所有能够帮助支持 Rust 项目维护者的努力，他们经常以志愿者身份从事几乎默默无闻且缺乏感激的工作，但同时这些工作又极其重要和必要。

感谢您考虑赞助 Rust 的开发和维护！您可以在我们的资金页面上找到有关资助 Rust 的更多信息。

1. 本计划的灵感来源于 Python 软件基金会（PSF）使用的驻场开发者概念，我们与他们进行了几次有益的讨论。谢谢您，PSF！ ↩

2. 请注意，GitHub Sponsors 目前在 rustfoundation GitHub 组织而非 rust-lang 组织上启用，这是一个可能在未来改变的实现细节。此赞助页面上筹集的所有捐款都将流向 Rust 基金会维护者基金，并将用于直接支持 Rust 项目维护者。 ↩

由 mimo-v2.5 模型翻译，花费 4204 tokens

感谢所有贡献者！<3

目录

• 旗舰目标：超越 &
  • 继续 Pin 人体工学实验
  • 设计语言特性以解决字段投影
  • Reborrow traits
• 旗舰目标：灵活、更快的编译
  • build-std
  • 生产就绪的 cranelift 后端
  • 推广并行前端
  • 重链接而非重建
• 旗舰目标：更高层次的 Rust
  • 人体工学引用计数：RFC 决策与预览
  • 稳定化 cargo-script
• 旗舰目标：解锁休眠的 traits
  • 演进 trait 层次结构
  • 就地初始化
  • 下一代 trait 求解器
  • 可稳定化的 Polonius 支持（nightly）
• 其他目标更新
  • 为 rustdoc 团队添加团队章程
  • a-mir-formality 中的借用检查
  • C++/Rust 互操作问题空间映射
  • Rust 的全面 niche 检查
  • 常量泛型
  • 继续解决 cargo-semver-checks 合并到 cargo 的阻塞问题
  • 开发保持 FLS 更新的能力
  • 在代码生成中发射 Retags
  • 扩展 Rust 参考手册以规范 Rust 语言的更多方面
  • 完成 libtest json 输出实验
  • 完成 std::offload 模块
  • 将 Rust for Linux 引入稳定 Rust：编译器特性
  • 将 Rust for Linux 引入稳定 Rust：语言特性
  • 实现 Open API 命名空间支持
  • MIR 移动消除
  • 原型化一套新的 Cargo "管道" 命令
  • 原型化 Cargo 构建分析
  • 反射与编译时
  • 重构 Cargo 构建目录布局
  • 在 Rust 的 CI 中为 GCC 后端运行更多测试
  • Rust 稳定化内存消毒器和线程消毒器支持
  • Rust 愿景文档
  • rustc 性能改进
  • 稳定化公开/私有依赖
  • 稳定化 rustdoc 的 doc_cfg 特性
  • AArch64 上的 SVE 和 SME
  • 类型系统文档
  • Unsafe 字段

旗舰目标：超越 &

继续 Pin 人体工学实验

• 参与人员： Frank King
• 倡导者： compiler (Oliver Scherer)， lang (TC)
• 状态： 已延续

设计语言特性以解决字段投影

• 参与人员： Benno Lossin
• 倡导者： lang (Tyler Mandry)
• 状态： 已延续

Reborrow traits

• 参与人员： Aapo Alasuutari
• 倡导者： compiler (Oliver Scherer)， lang (Tyler Mandry)
• 状态： 已延续

由 mimo-v2.5 模型翻译，花费 76158 tokens