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

These past two months have been incredibly busy. I didn't publish a status report for April 2026, so this status report will cover that, too.

We have mostly completed the migration from our self-hosted GitLab Enterprise instance to Radicle. There's still further work to be done, but the most crucial bits have made it over. We're also still working on ironing out some kinks in learning "the Radicle way". I hope soon to write an article chronicling our journey thus far.

I wrote documentation on how to bootstrap Radicle's local storage directory with src and ports. If you hope to someday submit issues and/or patches, following these bootstrap instructions will certainly ease the initial pain. I plan to include an export of these Radicle storage bootstrap archives with each official build. The current exports are not signed. I'm going to include the hashes in this signed email. I am working on a candidate patch to our build scripts to perform this export. The archives exported by our builder VMs will be signed with our normal ssh key-based signing method.

Fully fixing the release image generation (chiefly fixing generation of disc1.iso) is my first priority. Radicle bootstrap archive generation is my second priority. Radicle integration in our auto-sync is my third priority. Our commit emails came from GitLab. I need to replicate that functionality but with "the Radicle way." For now, I'm performing the sync myself when time permits (usually multiple times per day.)

The past couple months have also seen a number of FreeBSD security advisories, so we've published new builds for 16-CURRENT and 15-STABLE. Installer image generation is still somewhat broken, though I've seen some success with memstick.img. I plan to continue working on this until we're 100% fixed, though it will take time. It takes quite the number of hours to test even the smallest of changes. I get pretty much at most two attempts at testing fixes per day.

I spent some time studying Reticulum's code. I'm in the process of writing a shim to abstract how its backbone interface implementation uses select and friends. Back when I last looked at it, it required use of epoll. Simultaenously while I was working on that, I did notice the Reticulum project was working on a more portable backbone interface implementation. So I need to restart that research when the time comes.

I also spent a little bit of time with hbsdfw. I started work on forward-porting our 14-stable hbsdfw-specific patches to 15-STABLE. Then GitLab died, and my priorities switched to the Radicle migration. So I need to restart this research, too, when the time comes. I think I might target -CURRENT rather than 15-STABLE. That way, we don't have to periodically forward-port patches: we just maintain our patches against the naturally-evvolving hardened/current/master.

We completed the ISP account migration. Some pain is left to resolve. We lost support for our tunneled IPv6 (via Hurricane Electric's Tunnel Broker). I need to schedule a part of my day to capture some packets and get on the phone with some tech support folks on the side of both my ISP and HE. Until then, I've removed the AAAA DNS records for the relevant bits of infrastructure.

In src:

1. FreeBSD merged llvm 21 into base. We needed to fix one compilation error in HardenedBSD's code caught by llvm 21
2. Replace FreeBSD's README.md with our main wiki-based documentation.
3. Drop the -HBSD suffix in newvers.sh
4. Migrate hbsd-update-build to Radicle
5. Revert the release/ subdirectory to a known good-ish commit. This brought back generation of memstick.img
6. The hardening.pax.kmod_load_disable sysctl node logic was enhanced
7. Fix MK_LLVM_LINK_STATIC_LIBRARIES in src.opts.mk

In ports:

1. multimedia/ffmpeg build was fixed
2. ports-mgmt/pkg was updated to 2.7.5
3. ports-mgmt/poudriere-hbsd was updated to 3.4.8
4. A patch was brought in to fix the graphics/hdr_histogram port
5. hardenedbsd/secadm was updated to account for recent MAC hook changes by FreeBSD
6. Some incredibly basic support was implemented for downloading distfiles via Radicle HTTP
7. ports-mgmt/pkg was migrated to Radicle
8. The default llvm version was bumped to 21 for latest 16-CURRENT users
9. ports-mgmt/poudriere-hbsd was migrated to Radicle
10. COMPAT32 was disable for misc/compat{14,15}
11. PIE was disabled for devel/ccache4
12. net-p2p/reticulum was migrated to Radicle
13. hardenedbsd/secadm was migrated to Radicle

I want to say a heartfelt thank you to the Radicle folks. You've spent a lot of time in helping out. You didn't have to, but you chose to. And for that, I'm incredibly grateful. It's fun to see the Radicle network evolve.

==== BEGIN ARTIFACT HASHES ====
$ sha256 ports.tar.xz
SHA256 (ports.tar.xz) = b12f303b96b02b16744c1286868726ab4df43a06f6d28de3c247d4d1598f743b
$ wc -c ports.tar.xz
1472685664 ports.tar.xz
$ sha256 src.tar.xz
SHA256 (src.tar.xz) = 00301a70910127f4fd9564dca1be948e6b9909e864053a76b9197565768345cf
$ wc -c src.tar.xz
2069117660 src.tar.xz
==== END ARTIFACT HASHES ====

Before I get into the bulk of the status report, I want to give a heads up about ISP changes coming in April 2026. On 23 Apr 2026, I will disconnect internet service at our home and on 24 Apr 2026, internet service will be restored. This is to migrate the account from my personal finances to being under the HardenedBSD Foundation umbrella. This switch will save us $30 USD/month with no changes in bandwidth capacity (symmetric and uncapped 940Mbps).

In March 2026, I focused on Reticulum. I started studying its code and started work on the BackboneInterface code, porting it to HardenedBSD. I'm almost complete with my initial work-in-progress patch.

I also fixed the build issues for both 15-STABLE and 16-CURRENT. pkgbase support is still broken in our installers, so that will be a topic for this coming quarter.

As I write this report on the 29th of March, I am preparing the next quarterly branches and build.

In src:

1. Disable retpolines for the bootloader
2. Make sure the kinfo_file struct always gets zeroed

In ports:

1. 0x1eef's hardenedbsd/sourcezap and hardenedbsd/portzap were updated to 2.3.0.
2. Fix the build of security/snowflake-tor
3. ports-mgmt/pkg was updated to 2.6.2_1

January was a busy month with regards to infrastructure. With both OpenSSL and FreeBSD announcing security fixes, we published new builds just weeks after our new quarterlies dropped. :-)

Now that we have the new quarterlies, I plan to "MFC" (old FreeBSD CVS/SVN term for "Merge From Current".) Kids these days call it `git cherry-pick`. MFC is shorter to type, so that's what I'll use. I plan to MFC a number of commits made in hardened/current/master to the hardened/15-stable/main branch this week.

I've also received multiple reports of crashes with the 15-STABLE installer. I haven't been able to work on this just yet, but am hoping to in the next two weeks. It is almost my current first priority (the MFCs being first.) I figure that if testing the cherry-picked code proves successful, I could cherry-pick those commits into the relevant quarterly branch. Kind of a "thank you" gesture for being patient with me. :-)

I applied relevant updates across the entire infrastructure. I migrated the package repos from being served by a leased server with limited storage to out of my home with plenty of storage. My next goal is to fully automate the build, including syncing. This will mark a good next step to eventually supporting mirroring our package repos. It's much easier to transfer a 140GB package repo over a local 2.5Gbps LAN than a 150Mbps link upstream.

I spent some time experimenting with Meshtastic and Reticulum. I'm getting a better picture from a user's perspective on the current state of mesh networking. My next goal is to teach Reticulum's BackboneInterface implementation how to work on FreeBSD/HardenedBSD.

Two of the four donated Protectli devices are providing the testing lab for this Meshtastic and Reticulum research. Even though the timeframe has shifted pretty dramatically, I'm grateful for their donations and their support.

In src:

1. Opt ipfw into -ftrivial-var-auto-init=zero
2. Remove our old MAC hook for jail/prison destruction (this commit breaks building secadm. I'm waiting on upstream to implement a specific MAC hook, and a patch for (for src, not for secadm) is being worked on by FreeBSD's Kyle Evans.)
3. Disable WITNESS' checking of vnode locks by default. FreeBSD changed some vnode locking semantics and not all filesystem code paths have been updated. As such, we are seeing vnode locking-related panics. I need to get a consequtive block of time to dive in. I'm not a filesytems developer, so this one might take a while to figure out unless someone beats me to it.
4. rc.subr: Ignore required_modules failures in jails (patch submission by leper4{ _AT_ }protnmail.com.)

In ports:

1. Bump ftp/curl to 8.18.0
2. Update Reticulum to latest git HEAD
3. Disable HARDCFLAGS for devel/avr-gcc
4. Enable ZEROREG for security/openssl3*. This could induce a noticeable performance hit. Please let me know if you have any serious performance issues after this next package build.