HardenedBSD August / September 2026 Status Report

HardenedBSD 2026 年 8 月 / 9 月状态报告

I’m writing this status report a little early because this coming week (the week of the 28th of September 2026) is HardenedBSD quarterly release engineering week. On that note, I plan to cherry-pick a few “commits that smell like security” that FreeBSD recently made against their main branch into our 15-stable branch. I suspect over the next week or two, we might see a FreeBSD Security Advisory and/or Errata Notice.

我提前撰写了这份状态报告，因为接下来的一周（2026 年 9 月 28 日所在周）是 HardenedBSD 的季度发布工程周。在此期间，我计划将 FreeBSD 最近在其主分支中所做的一些“具有安全意义的提交”挑选（cherry-pick）到我们的 15-stable 分支中。我预计在未来一两周内，我们可能会看到 FreeBSD 的安全公告和/或勘误通知。

In src: Explicitly dissuade from pkgbase use (in bsdinstall) Update /etc/os-release and /var/run/os-release Enable -ftrivial-var-auto-init=zero for video(4) fix links in usr.bin/login/motd.template Document rejection of AI/LLM/etc generated works fix broken references in hardening(4) man page Harden ssh_config(5) by disabling compression and TCP keepalives by default Integrate -fbounds-safety in world with MK_BOUNDS_SAFETY, disabled by default The flag is still experimental, so it’s actually spelled -Xclang -fexperimental-bounds-safety In Ports: Fix broken dependency for math/libformfactor

在源码（src）方面：明确劝阻在 bsdinstall 中使用 pkgbase；更新 /etc/os-release 和 /var/run/os-release；为 video(4) 启用 -ftrivial-var-auto-init=zero；修复 usr.bin/login/motd.template 中的链接；记录拒绝使用 AI/LLM 等生成的内容；修复 hardening(4) 手册页中损坏的引用；通过默认禁用压缩和 TCP keepalives 来加固 ssh_config(5)；通过 MK_BOUNDS_SAFETY 将 -fbounds-safety 集成到系统中（默认禁用）。由于该标志仍处于实验阶段，其实际写法为 -Xclang -fexperimental-bounds-safety。在 Ports 方面：修复 math/libformfactor 的损坏依赖。

I’d like to chat a little bit about -fbounds-safety. This feature is not used anywhere in the base OS. And, the feature is currently disabled by default in HardenedBSD. However, adding the plumbing will allow folks downstream from us to more easily integrate that feature on their end. Folks building things with HardenedBSD can more easily use this experimental feature in their own code. Right now, we only integrated the flag with userland. Once the clang/llvm folks consider the feature production-ready, I’ll duplicate the logic to apply to the kernel and kernel modules. I view it similar to Capsicum: it requires direct integration in the project’s codebase. These approaches tend to feel heavy-handed to me. However, providing the plumbing in HardenedBSD will enable others to make the decision for themselves on whether (and where) it makes sense to adopt.

我想聊聊 -fbounds-safety。该功能目前在基础操作系统中并未被使用，且在 HardenedBSD 中默认处于禁用状态。然而，添加这些底层支持将使我们的下游用户更容易在其端集成该功能。使用 HardenedBSD 构建项目的开发者可以更轻松地在自己的代码中使用这一实验性功能。目前，我们仅将该标志集成到了用户态（userland）。一旦 clang/llvm 团队认为该功能已达到生产就绪状态，我将把同样的逻辑应用到内核和内核模块中。我认为它类似于 Capsicum：需要直接集成到项目的代码库中。这些方法对我来说往往显得有些笨重，但通过在 HardenedBSD 中提供这些支持，将使其他人能够自行决定是否（以及在何处）采用它。

Infrastructure: I applied updates across our infrastructure. I migrated two environments from VMs to jails: rad.hardenedbsd.org and ngx-01. We had issues the first 48 hours or so after the migration of both VMs to separate jails. This has drastically helped, though there are still latent issues. Please let me know if you have trouble browsing our Radicle node[1]. We are still experiencing (much) higher than normal traffic, so due to our throttling, browsing our Radicle web interface may require hitting Refresh occasionally. The next VM I plan to migrate to a jail is our rsync VM. I plan to do that after the next quarterly builds complete and are fully synced to our various mirrors. After rsync, I plan to modernize our Tor Onion Service endpoints. I also enhanced our auto-sync program to support pushing to multiple remotes. In related news, syncing to GitHub is now supported once again. So if running a local Radicle node isn’t your thing, you can reference our src and ports repos on GitHub. As of now, there are no plans to mirror to GitHub our auxiliary projects (hbsdmon, libhijack, vm-bhyve-hbsd, etc. Given that the sync to GitHub happens when we perform our autosync (every six hours), there can be some delay between when direct commits land in the Radicle network and are subsequently mirrored to GitHub.

基础设施方面：我对我们的基础设施进行了更新。我将两个环境从虚拟机（VM）迁移到了 jail 中：rad.hardenedbsd.org 和 ngx-01。在将这两个虚拟机迁移到独立的 jail 后，我们在最初的 48 小时左右遇到了一些问题。虽然迁移带来了显著改善，但仍存在一些潜在问题。如果您在浏览我们的 Radicle 节点[1]时遇到困难，请告知我。我们目前的流量仍然远高于正常水平，因此由于我们的限流措施，浏览 Radicle Web 界面时可能需要偶尔刷新。我计划下一个迁移到 jail 的虚拟机是 rsync VM，我打算在下一次季度构建完成并完全同步到各个镜像站之后进行。在 rsync 之后，我计划对我们的 Tor Onion 服务端点进行现代化改造。我还增强了自动同步程序，以支持推送到多个远程仓库。相关新闻是，现在再次支持同步到 GitHub 了。因此，如果您不习惯运行本地 Radicle 节点，可以参考我们在 GitHub 上的 src 和 ports 仓库。目前，我们没有计划将辅助项目（如 hbsdmon, libhijack, vm-bhyve-hbsd 等）镜像到 GitHub。鉴于同步到 GitHub 是在我们执行自动同步（每六小时一次）时进行的，直接提交到 Radicle 网络与随后镜像到 GitHub 之间可能会有延迟。

My long-term plan is to write an orchestration daemon in Rust that communicates directly with the Radicle node via its control socket. It’ll take action on the messages it sees on that socket. Think of it like “CI/CD lite”—something purpose-driven meant to satisfy HardenedBSD’s needs. Also, I really enjoy reading Rust code, but I’m still not profficient in writing Rust, so I want to take this as an opportunity to better hone my Rust language writing skills. Learning to write Rust better, anyways, will help me better submit patches to Radicle. There’s still a decent amount of work needed. For example, it’s possible to comment directly on a patch, but it’s not possible to list patch comments (and hence reply to them.) Unless someone beats me to it (yes, please, if you have spare cycles), I hope to work on scratching that itch once I become more accustomed to writing Rust.

我的长期计划是用 Rust 编写一个编排守护进程，通过控制套接字直接与 Radicle 节点通信。它将根据在该套接字上看到的消息采取行动。可以将其视为“轻量级 CI/CD”——一种旨在满足 HardenedBSD 需求的专用工具。此外，我非常喜欢阅读 Rust 代码，但我编写 Rust 的水平还不够熟练，所以我想借此机会磨练我的 Rust 编程技能。无论如何，学习更好地编写 Rust 将有助于我向 Radicle 提交补丁。目前仍有大量工作要做。例如，虽然可以直接在补丁上发表评论，但无法列出补丁评论（因此也无法回复它们）。除非有人抢先完成（如果有空闲时间，请务必尝试），否则我希望在习惯编写 Rust 后解决这个问题。

A note on the Radicle vulnerability announced[2] on 23 Sep 2026: To sum up the vulnerability, there are two issues at stake: A malicious node can coerce another node to disclose private repositories (and their contents.) Radicle’s traffic was thought to be fully encrypted. However, only the initial handshake is encrypted. The rest of the (long-lived) conversations between Radicle nodes is unencrypted. HardenedBSD does not use private repositories on the Radicle network. We provide a Tor Onion Service endpoint for our main Radicle seed node. Using our Tor Onion Service endpoint ensures that your Radicle node is communicating through an encrypted transit. So we’re not vulnerable to the private repo exposure issue. However, for those needing extra protection against traffic analysis, we suggest connecting to our Radicle node over Tor. I still believe Radicle to be the right choice for HardenedBSD. However, their eventual migration to iroh will impact HardenedBSD, its users, and its developers. There will likely need to be coordinated effort between the Radicle team, the HardenedBSD team, and the wider community. I will be paying very close attention to Radicle’s migration to iroh. It is unfortunate that these kinds of vulnerabilities happened. Having worked on OpenSSL code, and integrated other projects in my past with OpenSSL, I can understand how something like this happened. Writing robust APIs is rather difficult. At the same time, there should have been formal verification early on that things were working as desired. A simple tcpdump early on in development would have caught this. That said, I, too could have run tcpdump myself. However, I read over their documentation and took them at their word without verifying on my end. Same could be said for anyone and everyone even remotely interested in Radicle. We’re all human. We make mistakes. The Radicle team need to focus on…

关于 2026 年 9 月 23 日宣布的 Radicle 漏洞[2]的说明：总结该漏洞，涉及两个问题：恶意节点可以强迫另一个节点泄露私有仓库（及其内容）。人们曾认为 Radicle 的流量是完全加密的，但实际上只有初始握手是加密的。Radicle 节点之间其余的（长连接）通信是未加密的。HardenedBSD 在 Radicle 网络上不使用私有仓库。我们为主要的 Radicle 种子节点提供了 Tor Onion 服务端点。使用我们的 Tor Onion 服务端点可确保您的 Radicle 节点通过加密传输进行通信，因此我们不会受到私有仓库泄露问题的影响。不过，对于需要额外防范流量分析的用户，我们建议通过 Tor 连接到我们的 Radicle 节点。我仍然认为 Radicle 是 HardenedBSD 的正确选择。然而，他们最终向 iroh 的迁移将影响 HardenedBSD 及其用户和开发者。这可能需要 Radicle 团队、HardenedBSD 团队和更广泛的社区进行协调。我将密切关注 Radicle 向 iroh 的迁移。发生此类漏洞令人遗憾。我曾从事过 OpenSSL 代码的工作，并在过去将其他项目与 OpenSSL 集成，因此我理解这种情况是如何发生的。编写健壮的 API 非常困难。同时，早期应该进行形式化验证以确保系统按预期工作。在开发初期进行简单的 tcpdump 就能发现这个问题。话虽如此，我自己本也可以运行 tcpdump，但我阅读了他们的文档并轻信了他们，而没有亲自验证。对于任何对 Radicle 感兴趣的人来说，情况也是如此。我们都是人，都会犯错。Radicle 团队需要专注于……