Using `git tag` With HardenedBSD Automated Builds

[Shawn Webb]

Hey all,

Currently, when we perform our automated systems build installation
media/hbsd-update artifacts, we simply use the HEAD of the branch. We
only support three branches in the HardenedBSD source repository:

1. hardened/current/master (aka, 15-CURRENT)
2. hardened/current/cross-dso-cfi (aka, Cross-DSO CFI 15-CURRENT)
3. hardened/14-stable/master (aka, 14-STABLE)

Our next build is on 01 Jul 2025. We have time to make changes before
our next build (which will be our first official quarterly build).

Would it be helpful to the community to use a git tag in our build
system, rather than just the latest HEAD commit of a branch? Doing so
would provide the community with a definitive stamp of where the
project was at the time of build. However, I'm sure I have gaps of
knowledge regarding the src tree (and the build framework)--gaps which
might be impacted by using git tags. As of writing, `git describe` on
my local copy of hardened/current/master branch, shows
"vendor/ena-com/2.8.0-590577-g45c9a78c9d23" (without the quotes).

I would like to share my opinion, but I don't want my initial opinion
to influence the responses from the community. I want to hear from the
community first and respond after I absorb the comments.

I plan to make a firm decision by Friday, 27 June 2025. I will let the
community know which direction I'm leaning on 25 June 2025. Please
respond. Any/all input will help steer the direction of the project.

And, moreso, if you know of any edge cases, where using a `git tag` of
a non-release branch (aka, not FreeBSD's releng/* branches) might be
an issue, please especially let me know.

Thanks,

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Signal Username: shawn_webb.74
Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

[Shawn Webb]

Hey all,

It seems everyone I've chatted with is in favor of using git tags. I'm
leaning that direction as well.

So, I'm thinking of the following process:

1. At most 72 hours before the next quarterly build, I create a
quarterly branch.
2. After the branch is created, I then create the tag based on the
HEAD of that branch.
3. The automated build script will be updated to automatically support
the quarterly branch.

So, for hardened/current/master (aka, 15-CURRENT), I would create a
new branch named hardened/current/quarterly-2025q3, and a new tag
named hardened-current-quarterly-2025q3.

And for hardened/14-stable/master (aka, 14-STABLE), I would create a
new branch named hardened/14-stable/quarterly-2025q3, and a new tag
named hardened-14-stable-quarterly-2025q3.

Using an additional branch would enable us to cherry-pick security
fixes, enabling us to support minor security releases. If a new minor
release is being created, we would create a new tag, named similarily
to the original tag, but with r# appended, where the # is replaced
with an incrementing integer.

For example, the first 14-STABLE tag for 2025q3 would be named
hardened-14-stable-quarterly-2025q3. The second tag would be named
hardened-14-stable-quarterly-2025q3r1. If we needed to perform a third
security release in that quarter, the third tag would be named
hardened-14-stable-quarterly-2025q3r2.

Please let me know if you have any questions, comments, or concerns.

[Shawn Webb]

I'm currently working on upgrading our build scripts to handle
quarterly branches.

I've decided on branch names:

1. hardened/current/master -> quarterly/hardened/current/master-YYYYqN
2. hardened/current/cross-dso-cfi -> quarterly/hardened/current/cross-dso-cfi-YYYYqN
3. hardened/14-stable/master -> quarterly/hardened/14-stable/master-YYYYqN

Replace YYYY with the four-digit year and N with the quarter number.
For example, the next quarterly branch for 15-CURRENT will be named
quarterly/hardened/current/master-2025q3.

The tag will be named tags/BRANCH-YYYYqNpY. In this case, Y will be a
patch level. For example, the first quarterly tag for
hardened/current/master will be named
tags/hardened/current/master-2025q3p0. If we need to perform a
security release during the quarter, the commits will be cherry-picked
and a new tag will be created with Y incremented. So the first
security patch release will be named
tags/hardened/current/master-2025q3p1.