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.

In src:

1. Explicitly dissuade from pkgbase use (in bsdinstall)
2. Update /etc/os-release and /var/run/os-release
3. Enable -ftrivial-var-auto-init=zero for video(4)
4. fix links in usr.bin/login/motd.template
5. Document rejection of AI/LLM/etc generated works
6. fix broken references in hardening(4) man page
7. Harden ssh_config(5) by disabling compression and TCP keepalives by default
8. 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:

1. Fix broken dependency for 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.

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. 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.

A note on the Radicle vulnerability announced[2] on 23 Sep 2026:

To sum up the vulnerability, there are two issues at stake:

1. A malicious node can coerce another node to disclose private repositories (and their contents.)
2. Radicle's traffic was thought to be fully encrypted. However, only the initial handshake is encrypted. The rest of the (long-lived) conversations betwen Radicle nodes is unencrypted.

HardenedBSD does not use private repositories on the Radcile 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 adopting iroh, formalizing on-the-{,pseudo-}wire-traffic testing, and being more careful and focused with this next protocol iteration.

With all that said, I still want to be supportive of the Radicle team. They're already feeling pretty bad about making this level of magnitude mistake. They don't need anyone else piling on. Instead, they need our encouragement to get things right. Please be proactive in testing and, if you like writing Rust, help move them in that right direction.

[1]: https://radicle.network/nodes/rad.hardenedbsd.org
[2]: https://radicle.dev/2026/09/23/disclosure-of-vulnerability-in-network-pr...