【Rust日报】Rust 1.92.0 正式发布-编程阁

Rust 1.92.0 正式发布

本次更新主要集中在为“Never Type” (!) 的稳定化做准备、修复 Linux 平台上的 panic 回溯问题，以及稳定了一批标准库 API。

Never Type (!) 稳定化准备：
- 为了推进!类型（表示永远不会返回的类型）的最终稳定化，编译器将never_type_fallback_flowing_into_unsafe和dependency_on_unit_never_type_fallback这两个 lint 等级提升为Deny-by-default（默认为拒绝）。
- 这有助于在正式稳定前捕获那些可能因!类型回退规则变化而受损的代码。
Linux 下panic=abort的回溯修复：
- 现在即使在 Linux 上使用-Cpanic=abort编译，编译器也会默认生成展开表（unwind tables）。
- 这意味着即使在 abort 模式下 panic，现在也能正确生成回溯信息（backtrace），大大改善了调试体验。如果需要减小二进制体积，可以通过-Cforce-unwind-tables=no显式关闭。
宏导出参数校验：
- 对#[macro_export]属性的参数输入进行了更严格的校验，invalid_macro_export_argumentslint 现在默认拒绝（deny）。
Lint 改进：
- unused_must_uselint 现在更加智能，不再对返回Result<(), Uninhabited>（例如Result<(), !>）的函数发出警告，因为这种情况下错误分支在逻辑上是不可能发生的。

智能指针的零初始化：
- Box::new_zeroed,Box::new_zeroed_slice
- Rc::new_zeroed,Rc::new_zeroed_slice
- Arc::new_zeroed,Arc::new_zeroed_slice
- 这些方法允许直接创建内存清零的智能指针，对于 FFI 或性能优化场景非常有用。
读写锁降级：
- RwLockWriteGuard::downgrade：允许将写锁安全地降级为读锁，而无需释放锁，这在需要原子性地从“写”切换到“读”的场景中非常关键。
其他稳定 API：
- NonZero<uN>::div_ceil：非零整数的向上取整除法。
- Location::file_as_c_str：获取文件名为 C 字符串。
- BTreeMap的入口 API：btree_map::Entry::insert_entry,btree_map::VacantEntry::insert_entry。
- 为proc_macro::TokenStream实现了针对Group,Literal,Punct,Ident的Extendtrait。
Const 上下文：
- 切片的rotate_left和rotate_right方法现在可以在const函数中使用了。

Rustdoc 搜索优化：
- 搜索结果去重：如果搜索结果中包含某个 trait 的方法（如Iterator::last），搜索列表将自动隐藏具体实现该 trait 的类型中的同名方法（如Vec::last），从而减少冗余，让结果更清晰。
- 搜索词限制放宽：现在可以搜索不完全符合 Rust 标识符规则的词（例如以数字开头的搜索词），提升了搜索体验。

阅读：https://blog.rust-lang.org/2025/12/11/Rust-1.92.0/

Ubuntu 社区发起的一个新项目upki(Universal PKI)，旨在解决 Linux 系统长期以来缺乏统一的公钥基础设施（PKI），特别是证书吊销机制的问题。

Linux 系统长期以来依赖各个应用独自处理证书吊销，导致系统级软件安全性存在缺口。upki通过引入高效的 CRLite 技术并提供统一的系统服务，旨在填补这一空白，提升整个 Linux 生态系统的安全性。

1. 背景与问题：为什么需要这个工具？

OCSP 逐渐被弃用：Let's Encrypt 宣布将停止支持在线证书状态协议 (OCSP)，原因是其存在隐私泄露和可靠性问题。
CRL 在 Linux 上的缺失：作为替代方案的证书吊销列表 (CRL) 在 Linux 系统层面上缺乏统一的支持。虽然 Windows 和 macOS 都有系统组件集中处理 CRL，但 Linux 上的工具（如curl、包管理器、语言运行时）缺乏统一的机制来检查证书是否被吊销。
现状：目前只有浏览器（如 Firefox/Chrome）通过自建的基础设施较好地处理了这一问题，但其他系统级软件处于“裸奔”状态。

2. 解决方案：upki项目

项目简介：Canonical 与rustls维护者合作开发的一个开源通用 PKI 工具。
核心技术 - CRLite：
- 利用 Mozilla Firefox 采用的CRLite技术，将海量的 Web PKI 吊销数据压缩成紧凑、可高效查询的数据结构。
- 优势：极大地减少带宽消耗（相比传统 CRL 下载效率提升约 1000 倍）。
架构设计：使用Rust编写，包含三个主要角色：

3. 生态兼容性

C ABI 支持：除了 Rust 二进制文件，upki还将提供共享对象库（Shared Object Library）和稳定的 C ABI。
库集成：计划通过回调机制集成到OpenSSL、GnuTLS和rustls等主流加密库中，使现有的 C/C++ 程序也能利用本地缓存进行证书吊销检查。

4. 路线图 (Timeline)

阅读：https://discourse.ubuntu.com/t/addressing-linuxs-missing-pki-infrastructure/73314

讨论：https://www.reddit.com/r/rust/comments/1phhcwu/addressing_linuxs_missing_pki_infrastructure/

Rust 社区通过一项新 RFC 提案，计划在 crates.io 上直接集成 RustSec 漏洞数据库，增强官方包仓库 crates.io 的安全性透明度，让开发者在挑选第三方库时能即时看到安全风险，从而在开发早期规避潜在的安全隐患。

1. 核心提案：crates.io 新增“安全 (Security)”标签页

功能：建议在 crates.io 的每个 crate 详情页中添加一个专门的“Security”标签页。
数据来源：该标签页将直接展示来自RustSec 公告数据库（RustSec Advisory Database）的信息，由 Rust 安全代码工作组维护。
展示内容：包括该 crate 相关的已知漏洞（vulnerabilities）和不健全 API（unsound APIs）的公告、摘要、受影响的版本范围以及详情链接。
UI 交互：如果当前选中的 crate 版本受到某个公告的影响，该标签页可能会被高亮显示，以提醒用户注意。

2. 提案目的：安全左移

现状：目前开发者通常在代码编写完并运行 CI/CD 流程时，才通过cargo-audit等工具发现依赖项的安全问题。
改进：该提案旨在将安全上下文提前到“发现与选型”阶段。开发者在 crates.io 上浏览和决定是否使用某个库时，就能直接看到其安全历史和现状，从而做出更明智的决策，而无需等到引入依赖后才发现问题。

3. 范围与限制

针对目标：主要针对非恶意的漏洞（如无意的 bug 或 unsound 代码）。如果是恶意的 crate（恶意软件），crates.io 团队通常会直接将其删除，而不是仅仅发布公告。
避免过度惩罚：提案强调 UI 设计需要谨慎，避免将“有安全公告历史”简单地转化为负面的质量评分，因为流行的库由于受关注度高，往往会有更多的漏洞报告。

4. 当前状态