April was a busy month! There's a lot to get into, so here we go.

In src:

1. The pkgbase UCL template for HardenedBSD-related packages was fixed.
2. xz CVE-2025-31115 vulnerability was patched.
3. 0x1eef fixed `hbsdcontrol pax sysdef`.
4. 0x1eef fixed hbsdcontrol verb detection issues.
5. 0x1eef enhanced hbsdcontrol's help output.
6. FreeBSD recently introduced named attribute support for the open(2) syscall. HardenedBSD now rejects using named attribute file descriptors with fdlopen(3). I wrote a little proof-of-concept.
7. If hbsd-update fails to create the new ZFS boot environment due to the boot environment already existing, hbsd-update will no longer destroy the existing boot environment.

Nothing of note happened in the ports tree.

As discussed previously in the HardenedBSD Users mailing list, HardenedBSD will be slowing down the build cadence of OS builds (installers and hbsd-update) to once per quarter. This is primarily due to an issue with FreeBSD's latest release of the package manager, pkg. When building packages, pkg now takes a long time to calculate a given port's dependencies. This causes our 14-STABLE package build to now take longer than one month, up from just over two weeks.

Users who need a quicker cadence are encouraged to build src (and packages) themselves. We simply do not have the resources to speed up the build. The new installers/hbsd-update builds will take place on the first day of the following months: January, April, July, and October.

I plan on documenting a more formal release strategy, including the handling of security advisories, in the near future. I'm pondering whether we want to create quarterly branches in the src tree, and `git cherry-pick` security advisory fixes to those quarterly branches. That would prevent us from having to scrap an in-progress package build. But that comes at a cost of higher workload. So I'm weighing the pros/cons of various release strategies. I haven't made any firm decisions just yet. If anyone has any thoughts, please let me know.

I worked with the Radicle project to start testing HardenedBSD's src and ports trees. They've made a lot of progress on supporting larger repos. I worked on standing up a test Radicle network, to test importing src and ports and seeding them across a limited set of nodes. Each node is a separate HardenedBSD vnet jail. I came across some issues and need to report them more formally to the Radicle project. I'm grateful for their continued collaboration.

On the weekend of 25 April 2025, I attended a small FreeBSD hackathon focused on optional Rust toolchain support for userland applications. Attending were Alan Somers, Warner Losh, Brad Davis, Scott Long, and Reid Linnemann. I plan to tidy up a few things then announce a wider call-for-testing in May. You can follow along by watching the hardened/current/rust-in-base feature branch. I'd like to thank Alan Somers of the FreeBSD project for the opportunity to hack on this with him and the other FreeBSD developers in attendance--and for those who have provided valuable input.

One next step for the Rust-in-base work is to come up with a more formalized plan for vendor imports of third-party crates into the src tree. I imagine that to be a wider discussion point for figures upstream from us.

FreeBSD recently introduced limited pkgbase support in bsdinstall. Over the past few days, I've worked on updating our build scripts to support pkgbase. Our next build (in July) will include an experimental pkgbase repo for both 15-CURRENT/amd64 and 14-STABLE/amd64.

This status report includes January, since I missed publishing January's report. The last couple months have been busy, with progress being made on multiple fronts.

In the src tree:

1. PaX SEGVGUARD is now integrated with Capsicum. Capsicum violations now count against the process when the kern.trap_enotcap sysctl tunable is set. This feature was inspired by conversations with alip from Syd Linux.
2. A new sysctl tunable (hardening.elf_pie_only) was created to control whether non-PIE ELF executables are permitted to be executed. This feature was inspired by conversations with alip from Syd Linux.
3. _FORTIFY_SOURCE=2 was fixed for arm64.

In the ports tree:

1. Register zeroing (the new ZEROREG option) is now opt-in rather than opt-out. Several critical Python-related ports fail to build when ZEROREG is enabled by default for the entire ports tree.
2. Register zeroing was enabled for the following ports:
   1. dns/unbound
   2. irc/weechat
   3. net/openntpd
   4. net/rsync
   5. ports-mgmt/pkg
   6. security/openssh-portable
   7. security/openvpn
   8. security/tor
   9. www/firefox
   10. www/librewolf
   11. www/lighttpd
   12. www/nginx
   13. x11-servers/xorg-server
3. The build was fixed for security/wazuh-agent
4. CFI was enabled for net/rsync
5. The build was fixed for net/libfabric

Additional research and development was done for the BATMAN port to freebsd/hardenedbsd. The code doesn't compile, yet, but we're working on it. The goal for having something ready by the end of February wasn't acheived, but work is still being done. R&D is continuing, though at a slower pace than originally anticipated.

On the side of infrastructure, I got another server ready for deployment. We have a few servers waiting for deployment. On 12-13 March 2025, we will dramatically increase power capabilities in the server room in my home.

Since package builds take over two weeks to complete, I do NOT plan to start package builds until after the construction work is completed. It might be that the next package build will be 01 Apr 2025.

We will be able to deploy the two Cavium ThunderX1 arm64 servers and two amd64 servers. Cooling might become an issue, but at least we'll have the power capacity.

I deployed a new (well, new-to-us) NAS running HardenedBSD with 30TB usable capacity. I also deployed a little Protectli appliance for our internal DNS server and wrote a little script to update various DNS records when our IPv4 address changes.

All this infrastructure work would not be possible without donations from the community. We're able to expand due to the generosity of a few contributors. I would like to extend a heartful thank you to all who contribute to the project and the Foundation, no matter the form in which those contributions come--code, documentation, advocacy, funding, inspirational conversations, or otherwise.

This month saw a few improvements in HardenedBSD's source tree.

We can now boot to multi-user on the StarFive VisionFive2 riscv64 SBC dev boards. They use a 39-bit address space, so we had to tune down our ASLR deltas for this board as if we were operating on a 32-bit architecture. This is obviously far from optimal, but it's what we have.

Changes to the src tree:

1. Ensure libhbsdcontrol operates only on regular files.
2. Ensure hbsdcontrol does not follow symlinks by default. Provide an option to override.
3. Allow the RTLD ASLR delta to be overridden in the kernel config file.
4. Lower ASLR deltas for StarFive VisionFive2 SBC boards.
5. Drop TCP SYN+FIN packets by default.

In ports:

1. Do not override the default LLVM version in devel/electron32
2. Bring in the -ftrivial-var-auto-init=zero patch from HardenedBSD src for:
   1. devel/llvm17
   2. devel/llvm18
   3. devel/llvm19
3. Bump net-p2p/heartwood-httpd to 0.17.1
4. Disable _FORTIFY_SOURCE for:
   1. x11/swaylock
   2. x11/swaybg
   3. x11-wm/sway
5. Bump hardenedbsd/hbsdmon to 1.0_13
6. Disable PaX PAGEEXEC for www/firefox
7. Set default LLVM version to 19 for 15-CURRENT systems

We performed emergency maintenance on the 14-STABLE build server. We replaced three sticks of RAM. As of this writing, it appears we have to replace more sticks. Once the package build that's running right now finishes, we will do that.

We received a large donation specifically for the purchase of a new Framework laptop. That purchase has been made and we are awaiting shipping. The timing of this couldn't be better as the laptop I used to use for when I'm bed-bound is now too old to run modern HardenedBSD. (The problem being the video card is ancient and there are no supporte drivers for it.) Many of you know I have various random health issues (migraines, back injury, chronic fatigue), so having a more mobile system will help me be active where ever I am.

We will soon be ordering some new hard drives for our NAS server. Once ordered and installed, we will reconfigure how we are storing build artifacts. Right now, each build server has enough storage to store its own build artifacts. However, this means that when we perform maintnance on the build server, the build artifacts are temporarily unavailable. Centralizing artifact storage onto a NAS will enable us to be more efficient when performing maintanance. We plan to make that purchase in January 2025.

I have started a discussion with the FreeBSD Foundation, the HardenedBSD Foundation, the Colorado BSD User's Group, and the Google Summer of Code student Aymeric Wibo, to organize a hackathon in January or February 2025. This hackathon will be geared towards getting the BATMAN-adv mesh networking GSoC work to a state where it can be reviewed for merging into FreeBSD. I'm excited to see where this goes and its human rights impact as we design, build, and deploy surveillance- and censorship-resistant mesh networks.

The HardenedBSD Foundation is happy to announce a donation from the folks over at Protectli. Protectli is an open source firewall appliance company. This is their second donation to the HardenedBSD Foundation to date.

This donation is for a specific project: the development of a censorship- and surveillance-resistant mesh network. Protectli donated four FW4B devices. These devices will help us research and develop a prototype network, with the end goal being wider deployment once the initial proof-of-concept is developed and documented.

We--the HardenedBSD Foundation and the HardenedBSD Project--believe that Protectli offers a solid product line with which to base our reference implementation. We plan to start a concerted effort on the proof-of-concept implementation starting January through February 2025.

We are in talks with a Google Summer of Code contributor for FreeBSD in bringing their hard work to completion; or, at the very least, to a state that is usable for this project. The contributor, Aymeric Wibo, spoke at BSDCan 2024 about his efforts at porting BATMAN-adv to FreeBSD. We hope to bring his work into a special feature branch in HardenedBSD.

Special care must be taken so as not to introduce GPL code. Some bits of the BATMAN project are GPL. The bits that are BSD license compatible can land in the src tree, but GPL bits will land as ports entries.

Once we are satisfied with that work, we will begin work on a special version of HardenedBSD. This version will have all methods for capturing packets (eg, libpcap, tcpdump, BPF, etc.) removed. This would enable network operators to respond to law enforcement requests with a simple answer: "we have no customer data and lack the ability to capture customer data."

We envision networks akin to the NYC MESH project, with two key differences:

1. inter-mesh node connections will be encrypted (IPSEC, Wireguard, or OpenVPN);
2. Supernodes will route all outbound public Internet connections via Tor.

Node and Supernode operators will undergo a vetting process. Supernode operators must also run a public Tor relay to offset the bandwidth cost of users. Routing all traffic through Tor will place a large burden on the Tor network, so we must be kind citizens and try to offset that burden as much as possible.

Protectli plays a crucial role beyond this one donation. We are in talks with Protectli to establish a baseline set of equipment as gold standard. Network operators can supply their own equipment, but we will recommend Protectli as the "known working gold standard reference."

Node operators will be required to run hardened operating systems, with a strong recommendation of HardenedBSD.

We are grateful for Protectli's support of the HardenedBSD project and its goals. We dream of a decentralized digital world wherein safety of its participants is of utmost importance.

If you would like to play a part in this initial research and development, please reach out to the HardenedBSD Foundation at foundation@hardenedbsd.org.