Arti 2.5.0 发布：Counter Galois Onion 转正、默认开启拥塞控制，并修复两项 DoS 问题

Tor 项目的 Rust 实现 Arti 2.5.0 这次更新，终于把几个之前更多停留在“逐步完善中”的能力推到了更实用的阶段。最醒目的变化，是 Counter Galois Onion 现在被标记为稳定特性，并进入完整功能构建；与此同时，Congestion Control 也开始在默认构建里直接启用，不需要额外配置就能吃到速度收益。对一直关注 Rust 在匿名网络、隐私基础设施里落地的人来说，这意味着 Arti 不只是“用 Rust 重写 Tor”，而是在持续把协议实现往可部署、可默认启用的新阶段推进。

这次版本的另一个关键信号，是它把“性能推进”和“安全修复”放在了同一次正式发布里处理。官方公告提到，版本内同时修复了 TROVE-2026-024 和 TROVE-2026-027 两个中等严重度的 DoS 问题；也就是说，这不是一版单纯讲新功能的 release，而是把协议演进、默认性能策略和安全补丁一起打包交付。对基础设施项目来说，这种发布节奏本身就说明工程成熟度在往上走。

开发者侧也有一个需要注意的门槛变化：Arti 2.5.0 把 MSRV 提升到 Rust 1.91。如果团队里还有比较老的工具链或者锁得比较紧的构建环境，这次升级不只是 cargo update 那么简单，可能还会牵动 CI 镜像和内部依赖基线。但反过来看，这也说明 Arti 正在更积极地利用较新的 Rust 生态能力，而不是长期停在保守兼容线上。

更长一点看，这个版本依然在继续补齐 relay 和 directory authority 方向的能力。也就是说，Arti 的故事仍然不是“做一个能跑客户端的替代品”就结束，而是继续朝 Tor 更完整的角色集合靠近。对 Rust 社区而言，这类项目的价值很直接：它证明 Rust 在高安全要求、强协议约束、持续演进的网络基础设施里，已经不仅仅适合写外围工具，而是在承担核心实现。

原文：https://blog.torproject.org/arti_2_5_0_released/ 补充报道：https://alternativeto.net/news/2026/7/arti-2-5-brings-stable-counter-galois-onion-default-congestion-control-and-security-fixes/

原文链接：https://blog.torproject.org/arti_2_5_0_released/

wip：把 Rust 开发期“先跑起来再补正确性”系统化成 warning-first 工作流

这篇 Work In Progress Rust 文章很有共鸣点：Rust 的“正确性优先”固然是优势，但在复杂逻辑刚起草的时候，开发者经常会被 Result、边界条件、所有权细节频繁打断。作者的核心观点不是反对这些约束，而是强调一种更现实的工作流：先把主要逻辑推进到可测试状态，再把未完成部分明确地挂成 warning，最后在 CI 阶段强制清理。这个思路并不新，但作者把它系统化得很完整。

文章先梳理了很多 Rust 开发者都熟悉但不够优雅的临时技巧：比如先 unwrap()、先 clone()、用 todo!() 占位，或者拿文档注释伪装出“记得回来修”的编译提醒。作者承认这些手法在真实工程里确实有用，因为它们能让人暂时留在 happy path，不至于在实现主线逻辑时被每一个错误分支拖住。但问题也很明显：这些临时措施并不总会稳定地产生 warning，而且很容易在重构或合并前被忘掉。

因此文章最后落在作者做的 wip crate 上：它把 “WIP 阶段允许先欠债，但必须留下可见提醒” 这件事包装成了一套更明确的工具。比如用会稳定发出 warning 的 wip! 代替普通 todo!，用 unwrap_wip、clone_wip 这类扩展显式区分“开发期临时写法”和“准备进入最终代码的正式写法”。这类库不一定适合所有团队，但它提出的问题很真实：Rust 并不只需要最终正确性工具，也需要服务于开发中间态的工程化工具。

对 Rust 生态来说，这种文章和小 crate 的价值，在于它不是又一个“性能/安全/框架”话题，而是在认真讨论 如何更顺手地写 Rust。当语言逐渐进入更大团队、更复杂产品时，开发期体验本身也会越来越值得被单独产品化。

原文：https://blog.dureuill.net/articles/wip/ 项目地址：https://codeberg.org/dureuill/wip/

原文链接：https://blog.dureuill.net/articles/wip/

hiper 0.5.0：不用 proc-macro、零中间分配的 Rust HTML 模板 DSL

如果你一直把 Rust 模板生态大致分成 askama 这类“更接近传统模板文件”和 maud 这类“宏里直接写标记”，那 hiper 0.5.0 这次会挺值得看。作者给它的定位非常清楚：做一个 语法尽量接近 maud，但又坚持 不用 procedural macro、尽量零中间分配、甚至零依赖 的渲染 DSL。换句话说，它不只是再做一个“也能写 HTML 的宏”，而是在模板 ergonomics 和底层约束之间走了一条很明确的路线。

README 里最值得注意的，是它把这些卖点落到了具体设计上：模板可以像 Rust 代码一样通过函数组合；宏语法支持 tag、id、class、条件 class、可选属性和值表达式；渲染时尽量避免中间字符串分配。作者还专门把它和 maud、horrorshow、vy、askama 摆在一起比较，等于主动回答“为什么已经有这么多模板方案了，你还要再做一个”。其中最核心的差异点就是：hiper 追求的是声明宏方案下尽可能接近现代模板 DSL 的写法。

这条项目的意义不一定在于它马上取代谁，而在于它继续把 Rust Web/UI 模板这条线往前拧了一圈：原来除了 proc-macro + DSL，还可以认真探索 decl_macro + 零分配 的路径。对一部分在意编译开销、依赖控制和渲染性能的开发者来说，这种取舍会很有吸引力。

如果后续它继续完善基准、生态集成和大型模板场景下的可维护性，hiper 很可能会在“偏极简、偏性能、偏 Rust 原生语法”的模板工具里占住自己的位置。

原文：https://github.com/lsunsi/hiper crate 地址：https://crates.io/crates/hiper 文档地址：https://docs.rs/hiper/latest/hiper/

原文链接：https://github.com/lsunsi/hiper

efimux：Ratatui 跑进 UEFI，做出一个真正可用的 EFI 多路启动器

efimux 这条很容易让人眼前一亮，因为它把不少人印象里“更像 Linux 用户态 TUI 工具”的 Ratatui，直接带进了 UEFI 场景。项目的定位非常直白：它是一个 EFI application multiplexer，也就是在启动阶段用于引导其他 EFI 应用的多路入口。比起单纯展示“Rust 也能写 UEFI 程序”，这更接近一个能被实际拿来玩的 end-user 工具。

从工程意味上看，这个项目好玩的地方在于，它不是在普通终端里跑，而是在非常受限、很少有人会首先想到做“界面体验”的启动环境里，把 TUI 这层用户交互做了出来。作者 README 里明确提到它基于 uefi-rs 教程路线，同时提供了相对完整的制作方式：分区、格式化 FAT、把生成的 efimux.efi 放到 efi/boot/bootx64.efi。这说明它不是概念截图，而是一个确实能被写进 U 盘、实际启动测试的项目。

如果只从传播性来看，efimux 的亮点也很足：“Ratatui in UEFI” 本身就很抓人。Rust 这些年在嵌入式、系统启动链路、no_std 等方向一直有稳定受众，但很多项目仍然偏底层能力展示；efimux 更接近“把底层能力做成一个一眼能看懂用途的作品”。这类项目往往特别适合给外部开发者建立直觉：Rust 不只是能写内核、驱动、loader，也能在这些地方写出像样的交互界面。

如果后面它继续扩展对更多 EFI 应用的管理体验、启动项组织或者更成熟的设备发现逻辑，这条线完全可能从“有趣作品”继续长成一个更像样的启动工具。

原文：https://github.com/sermuns/efimux Ratatui：https://ratatui.rs/

原文链接：https://github.com/sermuns/efimux