HEADS UP: Potential delays with the next quarterly release

[Shawn Webb]

Hey all,

I am supposed to start the quarterly release engineering process this
weekend. However, due to a family emergency, that process might be
delayed. As we get closer to the weekend, I'll provide an update to
this thread with a concrete determination.

Thanks,

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Signal Username: shawn_webb.74
Tor-ified Signal: +1 (719) 756-1197 / activist_opsec.27
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

[Shawn Webb]

On Mon, Jun 22, 2026 at 05:52:09PM +0000, Shawn Webb wrote:
> Hey all,
>
> I am supposed to start the quarterly release engineering process this
> weekend. However, due to a family emergency, that process might be
> delayed. As we get closer to the weekend, I'll provide an update to
> this thread with a concrete determination.

Hey all,

The quarterly builds are currently postpooned. The build process
itself is fully automated (via cron), but the release engineering
process (major bits outlined below) prior to the builds is (and I
believe always should be manual by a human):

1. Creating the initial quarterly branches
2. Incorporating late-breaking patches
3. Performing and testing builds
4. Rinse and repeat for each and every supported branch
(hardened/current/master, hardened/15-stable/main,
hardened/current/cross-dso-cfi, hardened/current/pledge.)
5. Resolve issues if testing proves unsuccessful

It's those pre-build release engineering steps I originally had
planned for the weekend. My efforts are needed elsewhere.

So, I've disabled the cron jobs. I'm hoping to create the new
quarterly branches themselves this weekend, but that's still just
"hope" status: can't guarantee it right now.

Thank you everyone for your understanding and patience,

[Shawn Webb]

On Sat, Jun 27, 2026 at 02:08:07AM +0000, Shawn Webb wrote:
> On Mon, Jun 22, 2026 at 05:52:09PM +0000, Shawn Webb wrote:
> > Hey all,
> >
> > I am supposed to start the quarterly release engineering process this
> > weekend. However, due to a family emergency, that process might be
> > delayed. As we get closer to the weekend, I'll provide an update to
> > this thread with a concrete determination.
>
> Hey all,
>
> The quarterly builds are currently postpooned. The build process
> itself is fully automated (via cron), but the release engineering
> process (major bits outlined below) prior to the builds is (and I
> believe always should be manual by a human):
>
> 1. Creating the initial quarterly branches
> 2. Incorporating late-breaking patches
> 3. Performing and testing builds
> 4. Rinse and repeat for each and every supported branch
> (hardened/current/master, hardened/15-stable/main,
> hardened/current/cross-dso-cfi, hardened/current/pledge.)
> 5. Resolve issues if testing proves unsuccessful
>
> It's those pre-build release engineering steps I originally had
> planned for the weekend. My efforts are needed elsewhere.
>
> So, I've disabled the cron jobs. I'm hoping to create the new
> quarterly branches themselves this weekend, but that's still just
> "hope" status: can't guarantee it right now.

Hey all,

I'm back home. I will start on the quarterly release engineering
(commingly abbreviated as "releng" in the BSD camp) process today. I
hope to have the 2026q3 release published by the end of this coming
weekend.

Thank you everyone for your patience, understanding, and support. It
really means a lot--especially right now.

Thanks,

[Shawn Webb]

Over the past couple days, FreeBSD has introduced a number of "smells
like security" commits in their main development branch. They have one
week MFC period (meaning, let the commits soak for testing in main,
then cherry-pick to the relevant stable branches along with any
subsequent commits to fix various (potential) bugs.

The problem I'm trying to solve is this: I just barely started the
release engineering process and the timing of these commits upstream
presents some challenges (to no fault of upstream--mainly a timing
issue.

Once my initial testing of the HardenedBSD hardend/current/master
branch is complete, I plan to cherry-pick the relevant commits to the
hardened/15-stable/main branch.

Since I'm shortening the MFC period downstream, I plan to do
additional testing. This could add an extra couple days to the next
15-STABLE build. I suspect some of these commits might be worth the
wait.

[Shawn Webb]

New quarterly builds out for the following branches:

1. hardened/current/master (aka, 16-CURRENT)
2. hardened/15-stable/main (aka, 15-STABLE)

I plan to let my body recover for a bit this weekend. I'll work on the
following feature branches early next week:

1. hardened/current/cross-dso-cfi (aka, 16-CURRENT with Cross-DSO CFI)
2. hardened/current/pledge (aka, 16-CURRENT Pledge port feature
branch)

I'll make sure their relevant quarterly branch is up-to-date related
to the quarterly/hardened/current/master-2026q3 branch I created.

Prior to the switch to Radicle, I would create signed git tags for the
quarterly branches. I need to update the "Radicle Repository Identity
Document" and add our tags as explicit "canonical references." I think
I want to formalize a strategy around the delegation list for the
quarterly branches and tags.

Radicle's way of doing canonical branches and delegates provides some
very cool security aspects that I would like to take advantage of.
Previously, I could do the release engineering work on any system on
which my ssh key material was uploaded to our self-hosted GitLab.

Now, with Radicle, I can limit which nodes are able to advance the
HEAD of a canonical reference. This means that I can have my
development VMs be able to advance the HEAD of the main development
branches and the quarterly branches. I could have a whole separate set
of nodes that can advance the HEAD (or even initially create) the
`refs/tags/quarterly/*` globbing pattern (or similar).

You can see that for the quarterly branches, the threshold is 2. That
means that at least two delegate nodes must explicitly accept the same
HEAD state in order for the wider Radicle network to accept the
advancement of HEAD.

I really like this "permissions model" so-to-speak. It provides an
immense level of both flexibility and power in an intuitive
manner--even if my explanation of what's in my brain might not be
sufficient. They have great documentation. Their user guide can be
found here[1].

For a reference of what that identity document looks like for ports
and src, take a look at our documentation[2] on the matter. I will, of
course, update that document when I do make the change to support git
tags.

[1]: https://radicle.dev/guides/user
[2]: https://radicle.network/nodes/rad.hardenedbsd.org/rad:z4Aucnb2nozutuek6o8PC9YfaBeTm/tree/Delegates.md