HardenedBSD April 2025 Status Report

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.