HardenedBSD 2026年八月与九月状态报告

# HardenedBSD 2026年8月/9月状态报告 来源：https://hardenedbsd.org/article/shawn-webb/2026-09-27/hardenedbsd-august-september-2026-status-report 我提前撰写这份状态报告，因为本周（2026年9月28日所在周）是HardenedBSD的季度发布工程周。借此机会，我计划从FreeBSD主分支近期提交的几个“具有安全气息”的提交中挑选部分，整合到我们的15稳定分支。我预计未来一两周内，我们可能会看到FreeBSD发布安全公告和/或勘误通知。 **源代码（src）更新：** 1. 在bsdinstall中明确建议不要使用pkgbase 2. 更新/etc/os-release和/var/run/os-release文件 3. 为video(4)子系统启用-ftrivial-var-auto-init=zero编译选项 4. 修复usr.bin/login/motd.template中的链接问题 5. 新增文档说明拒绝接受AI/LLM等生成的内容 6. 修复hardening(4)手册页中的错误引用 7. 通过默认禁用压缩和TCP保活机制来加强ssh_config(5)安全性 8. 通过MK_BOUNDS_SAFETY集成-fbounds-safety至用户态（默认禁用）——该标志仍属实验性功能，实际语法为`-Xclang -fexperimental-bounds-safety` **软件仓库（Ports）更新：** 1. 修复math/libformfactor的损坏依赖关系 我想详细谈谈-fbounds-safety特性。该特性尚未在基础操作系统中应用，且在HardenedBSD中当前默认禁用。不过添加相关基础设施能让下游使用者更便捷地集成此特性。基于HardenedBSD构建项目的开发者可在自身代码中更轻松地运用这个实验性功能。目前我们仅在用户态集成了该编译选项，待clang/llvm开发团队认为该功能达到生产级别后，我会将相同逻辑扩展至内核及内核模块。 我将其视同Capsicum：需要直接集成到项目代码库中。这类方案往往显得较为重量级，但在HardenedBSD中提供基础设施能赋予其他项目自主决策权，自行判断是否（以及在何处）采用该特性。 **基础设施更新：** 我对整体基础设施进行了升级。已将两个环境从虚拟机迁移至容器：rad.hardenedbsd.org和ngx-01。在两台虚拟机分别迁移至独立容器的初期48小时内曾出现问题。虽然现已大幅改善，但仍有潜在问题待解决。 如您在访问我们的Radicle节点[1]时遇到困难请告知。我们仍承受着远超常态的流量压力，因此由于速率限制，浏览Radicle网页界面可能需要偶尔刷新页面。 下一台计划迁移至容器的虚拟机是我们的rsync服务。我计划在下次季度构建完成并完全同步至各镜像站点后执行该操作。完成rsync迁移后，我将着手升级我们的Tor洋葱服务端点。 我还增强了自动同步程序以支持推送到多个远程仓库。相关进展：GitHub同步功能现已恢复。如果您不习惯运行本地Radicle节点，可在GitHub上引用我们的src和ports仓库。目前没有计划将辅助项目（hbsdmon、libhijack、vm-bhyve-hbsd等）镜像至GitHub。 由于GitHub同步在执行自动同步时进行（每六小时一次），从Radicle网络直接提交到GitHub镜像之间可能存在延迟。我的长期计划是使用Rust编写一个编排守护进程，通过控制套接字直接与Radicle节点通信。它将根据套接字接收的消息采取行动，可视为满足HardenedBSD需求的“轻量级CI/CD”系统。另外，虽然我很享受阅读Rust代码，但目前尚未精通Rust编写，正好借此机会提升我的Rust编程能力。 提升Rust编写能力也有助于我向Radicle项目提交补丁。目前仍存在不少待完善之处，例如虽然可以直接评论补丁，但无法列出补丁评论（因此无法回复评论）。除非有人先行解决（若您有空闲时间欢迎贡献），我计划在熟练掌握Rust后着手完善这个功能。 **关于2026年9月23日披露的Radicle漏洞说明[2]：** 该漏洞主要涉及两个问题： 1. 恶意节点可诱导其他节点泄露私有仓库（及其内容） 2. 本以为Radicle流量完全加密，但实际上仅初始握手加密，节点间后续长期对话内容均为明文传输 HardenedBSD不在Radicle网络使用私有仓库。我们为主Radicle种子节点提供了Tor洋葱服务端点，通过该端点通信可确保流量经过加密传输。因此我们不会暴露于私有仓库泄露风险，但对需要额外流量分析防护的用户，建议通过Tor连接至我们的Radicle节点。 我依然认为Radicle是HardenedBSD的正确选择。然而他们向iroh的最终迁移将影响HardenedBSD、用户及开发者。可能需要Radicle团队、HardenedBSD团队及更广泛社区的协同配合。我将密切关注Radicle向iroh迁移的进展。 这类漏洞的发生令人遗憾。曾参与OpenSSL代码开发并集成过其他项目的我，能理解这类问题的成因。编写健壮的API确实颇具挑战。 同时，理论上应更早进行形式化验证以确保功能符合预期。开发初期简单的tcpdump抓包就能发现此问题。当然，我自己本也可进行tcpdump测试，但我查阅文档后轻信了他们的说明而未亲自验证。所有对Radicle有兴趣的人都可能犯类似错误。 人非圣贤，孰能无过。Radicle团队应集中精力完成iroh迁移、形式化线上流量测试，并在下次协议迭代中更加严谨专注。 尽管如此，我仍希望支持Radicle团队。他们已为此次重大失误深感自责，无需更多指责。相反，他们需要我们的鼓励来正确解决问题。请积极测试，若擅长Rust开发，请帮助他们朝着正确方向前进。 \[1\]:https://radicle.network/nodes/rad.hardenedbsd.org \[2\]:https://radicle.dev/2026/09/23/disclosure-of-vulnerability-in-network-protocol.html