Toying around with #Radicle on #HardenedBSD by working with issues.

I created a new issue to track fixing the devel/ccache4 port, worked through it, and closed it as solved after committing the fix.

My next major change in the ports tree will be completing the USE_RADICLE support. I got it to the point where it supports basic distfile fetching and hashing. But, it's a rather naive implementation, only meant to serve as a "get things working good enough for now."

There's still a lot of work to be done. I plan to use Radicle's patch workflow when finishing up USE_RADICLE support.

@sigsegv44

Even more reason to run #OpenBSD and #HardenedBSD!

https://cgit.freebsd.org/src/commit/?id=e68433e1990d5f1bcc1bdd270d65f1e4792a8e1b

This is the kind of bug that #HardenedBSD protects against with its kmalloc hardening feature. It forces memory zeroing upon both allocation and free. My own non-build systems (laptops and non-build servers/VMs) all run with hardening.kmalloc_zero=1.

#FreeBSD #infosec

sys: Fix heap disclosure in compat7 kern.proc.filedesc sysctl - src - FreeBSD source tree

The performance of the #git binary on #HardenedBSD has really taken a dive recently. I'm wondering if some of our hardening features are hitting git itself hard. Other applications seem absolutely fine.
@hyperreal Correct. The #HardenedBSD seed node runs only the #Radicle node and the radicle-httpd. That should suffice for the majority of cases for seed nodes (or any node needing HTTPS access to repos.)

@hyperreal Hey! I've been toying with #Radicle recently, too!

A seeder is simply a (generally speaking, public) Radicle node that accepts inbound connections and simply provides a system from which others can sync from. Kinda like seed nodes on bittorrent, but also kinda not. Generally, seed nodes do not perform commits, open issues, or create patches.

They're simply there to provide access to the repos configured in the node's policy.

#HardenedBSD has a dedicated seed node, too: https://radicle.network/nodes/rad.hardenedbsd.org

Lemme know if you have any other questions. I'm still learning the Radicle ropes, but I've been learning a lot along the way.

Radicle Explorer

Explore the Radicle network

BSD-NL Conference - Early 2026 is over, already... πŸ‘πŸ˜ˆβ›³

We would like to thank all the attendees who made time to visit us in Utrecht.
And of course our wonderful speakers:

πŸ“Ή https://exquisite.tube/w/38gDYhMNTNZimk3GcFnHNa
🌐 https://events.bsdnl.nl/early2026/talk/W9P9RT/
🎀 Let's find out how to get predictable IPv6 addresses assigned to OpenBSD VMs
by Florian Obser

πŸ“Ή https://exquisite.tube/w/dkV6kWiT9sp2y6xVwkH1iF
🌐 https://events.bsdnl.nl/early2026/talk/BGGPZQ/
🎀 On DOS, floppies, NetBSD and nostalgia
by Eirik Øverby

You can see older videos at: https://exquisite.tube/c/bsdnlconference/videos

See you next time!

#BSDNL #RUNBSD #BSD #OpenBSD #FreeBSD #NetBSD #HardenedBSD #SecBSD #DragonflyBSD

Today is the BSD-NL Conference - Early 2026 πŸ‘πŸ˜ˆβ›³

In between all the hacking and slacking there will be talks!

You can catch the stream on: https://exquisite.tube/c/bsdnlconference/videos

🌐 https://events.bsdnl.nl/early2026/talk/W9P9RT/
🎀 Let's find out how to get predictable IPv6 addresses assigned to OpenBSD VMs
by Florian Obser

🌐 https://events.bsdnl.nl/early2026/talk/BGGPZQ/
🎀 On DOS, floppies, NetBSD and nostalgia
by Eirik Øverby

The full schedule πŸ“… https://events.bsdnl.nl/early2026/schedule/

πŸ“† 2026-05-09 / May 9th 2026
πŸ• 10:00-23:00 CET
πŸ“ Brouwerij Maximus (Utrecht)
🌐 https://bsdnl.nl

#BSDNL #RUNBSD #BSD #OpenBSD #FreeBSD #NetBSD #HardenedBSD #SecBSD #DragonflyBSD

BSD-NL Conference

Meeting once, or twice a year, at EuroBSDCon, BSDCan or AsiaBSDCon isn’t enough! So we decided to start BSD-NL, The BSD Community in The Netherlands. https://bsdnl.nl For all your *BSD needs, eithe...

Exquisite.tube
Current status: Updating the #HardenedBSD documentation to reflect the migration from self-hosted #GitLab to #Radicle.

Current status: Attempting to fix the build of devel/libclc on #HardenedBSD 16-CURRENT. #FreeBSD recently bumped #llvm in their main development branch to llvm 21.

Whenever the llvm major version is bumped in src, we need to bump the default llvm version in ports. This is because we build base libraries with LTO, and llvm's LTO implementation is not forward-compatible.

Meaning, the default llvm version in ports must be equal to or higher than the version in src.