https://forum.defcon.org/ https://hardenedbsd.org/)]]> en Fri, 01 May 2026 11:56:59 GMT vBulletin 60 https://forum.defcon.org/images/misc/rss.png https://forum.defcon.org/ https://forum.defcon.org/node/255479 Wed, 04 Mar 2026 21:39:21 GMT
As I write this, I'm narrowing that down further to the specific commit. I'm hoping to have this resolved this month. If I find and fix the problem this week, I will create new builds for folks to use. Otherwise, the next scheduled regular quarterly build is for 01 Apr 2026.

I appreciate everyone's patience on this. This has been a tricky bug (at times, it fit the description of a "heisenbug"). My spare time is limited (I have a rather large amount of tasks/obligations in everyday ${LIFE} right now), so it has naturally taken a long while to get to this point.

While inbetween clients at my dayjob, I have been granted the opportunity to research meshtastic and other mesh networking projects. I'm getting a lot closer in my censorship- and surveillance-resistant mesh network proof-of-concept. I'm now at the point where I need to port Linux-specific code to HardenedBSD. I'm hoping to get normal tcp/ip packets flowing through Reticulum nodes on the inside of six months. This project, announced in partnership with Protectli one-and-a-half years ago[1], is starting to move along at a nice pace. I will have more to share on that by the next status report.

On Saturday, 28 Feb 2026, I had given my local Hackers N' Hops chapter a little show & tell of Meshtastic, Reticulum, and HardenedBSD. I met with a bunch of really cool hacckers there, and demoed two Reticulum RNodes backed by Reticulum instances on two HardenedBSD laptops. I demoed an exec-over-meshtastic Python script I wrote the day prior. The script is available on Radicle as rad:z44pvAJS7SiQf2CGtpn8hY44GDMyu.

Speaking of Radicle, I plan to migrate some of my personal repos away from our self-hosted GitLab and onto the Radicle network. With time, I'm hoping to migrate us completely towards Radicle. Now would be a good time for those who want to contribute to HardenedBSD to start playing around and experimenting with Radicle.

In src:

1. Contributor "gmg" hardened the kernel crashdump interface.
2. Opt zlib kernel module into -ftrivial-var-auto-init=zero.
3. bsdinstall(8): Align us more closely with FreeBSD.

In ports:

1. net-p2p/reticulum was updated to 1.1.3_2
2. Disable PaX PAGEEXEC and PaX NOEXEC for science/zotero
3. Bring in candidate patch to fix dns/unbound
4. Hook hardenedbsd/ctrl into the build
5. 0x1eef added a new port: hardenedbsd/ctrl
6. Bump ports-mgmt/pkg to 3.5.1_1
7. 0x1eef updated a port: portzap v2.1.1
8. 0x1eef updated a port: sourcezap v2.1.1

Once I have figured out what's going on with the 15-STABLE panic and have a proper fix in place, I plan to quickly switch gears towards hbsdfw. I haven't produced a working hbsdfw build in a long time, and it's far past due. After that, I plan to switch right back to the Reticulum research and development.

I'll make sure to keep the community informed of the 15-STABLE findings and fixes.
]]> HardenedBSD shawn.webb https://forum.defcon.org/node/255479 https://forum.defcon.org/node/255389 Wed, 04 Feb 2026 16:50:03 GMT
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.

]]> HardenedBSD shawn.webb https://forum.defcon.org/node/255389