#hardenedbsd

TIL you can nullfs mount a #ZFS snapshot. This could be particularly useful for making sure jail root filesystems are absolutely 100% immutable: hbsd-current-02[shawn]:/home/shawn $ uname -a FreeBSD hbsd-current-02 16.0-CURRENT FreeBSD 16.0-CURRENT #0 hardened/current/master-n196551-d4411c7c9cc3-dirty: Wed Sep 16 19:42:46 UTC 2026 shawn@hbsd-current-02:/usr/obj/usr/src/amd64.amd64/sys/HARDENEDBSD amd64 hbsd-current-02[shawn]:/home/shawn $ sudo mount -t nullfs /usr/ports/.zfs/snapshot/2026-07-24_before /mnt $ ls -l /usr/ports | head -n 5 total 3215 -rw-r--r-- 1 shawn shawn 149175 Oct 7 00:59 CHANGES -rw-r--r-- 1 shawn shawn 727 Apr 26 18:13 CONTRIBUTING.md -rw-r--r-- 1 shawn shawn 1412 Apr 26 18:13 COPYRIGHT -rw-r--r-- 1 shawn shawn 13370 Oct 1 18:46 GIDs hbsd-current-02[shawn]:/home/shawn $ mount | grep nullfs /usr/ports/.zfs/snapshot/2026-07-24_before on /mnt (nullfs, local) hbsd-current-02[shawn]:/home/shawn $ touch /mnt/blah touch: /mnt/blah: Read-only file system hbsd-current-02[shawn]:/home/shawn (1) $ echo ohai > /mnt/README zsh: read-only file system: /mnt/README #FreeBSD #HardenedBSD #infosec #OpenZFS

I'm glad I switched #HardenedBSD away from #GnuPG to #OpenSSH based (detached) signatures. Not saying there's zero bugs in OpenSSH, but it seems to me (with zero factual research) OpenSSH has a better overall security posture than the alternatives. #infosec #gpg

Our Mastodon instance is powered by #OpenBSD. The media storage, however, is powered by #HardenedBSD. Our Mastodon media is about 1,3TB - including 30 days of remote cache. Adding the storage of our PeerTube instance triples that amount. Using any other filesystem than ZFS makes no sense whatsoever with storage arrays like this. And for ZFS, HardenedBSD is the most logical choice. The benefits of FreeBSD with added exploit mitigations and other security measures. Plus, a project that actively advocates and works for human rights!

HEADS UP: The #HardenedBSD ports tree has been force pushed. This has ramifications for those who use our ports git repository: https://groups.google.com/a/hardenedbsd.org/g/users/c/o4Fs_RhND5o #FreeBSD

@winterschon@mastodon.bsd.cafe @ptribble@mastodon.illumos.cafe @dexter@bsd.network Can confirm that Eva is awesome and true to her word. She has donated quality and functional hardware to #HardenedBSD. And she doesn't ask for anything in return. :-)

#HardenedBSD 16-CURRENT/amd64 package repo updated.

#HardenedBSD 16-CURRENT OS installer images and updates published to account for recent #FreeBSD security advisories. #infosec

#Radicle is working fine for #HardenedBSD src and ports between two laptops on the same physical network. But, it's not working in the slightest on the HardenedBSD infrastructure. I cannot get the seed node fully fetching the repos. Radicle just times out. The biggest issue is that it will try to restart the fetch from the very beginning upon failure. So we're transmitting the same exact data many, many, many, many, many, many times only to end up failing again. Radicle should probably archive the data at the point of failure, then when restarting the fetch, it can start from where it left off. Otherwise, we're experiencing first-hand the populist definition of insanity: doing the same thing over and over and over again but expecting different results.

#HardenedBSD HEADS UP: Our oligarchic overlords with their legion of AI bots have decided that our GitLab isn't powerful enough to line their pockets with our code. I've now powered off our self-hosted GitLab and disabled the autosync. I'll pull an all-nighter tonight to see if we can switch to Radicle. If that fails, I'm not sure what to do. It's evident that we need a whole new fleet of servers just to handle the load and ain't nobody got funds for that.