ci: publish the pfSense packages as release assets

The pfSense packages were kept out of releases by design, as workflow
artifacts, until one had been installed on a real pfSense box. That bar
has been met on the two supported Plus bases: install, boot script
lifecycle, log rotation, DNS through unbound, the package reload path,
reboot, teardown and removal on Plus 26.03.1 and 26.07 in Netgate-installed
VMs, and mesh traffic between the two over the TUN interface under pf;
the README's test record has the details.

The release job now needs the pfsense job as well as build, downloads
its artifact next to the FreeBSD one, and requires all three packages
before publishing instead of failing if a pfSense package is present.
Their checksums join checksums-freebsd.txt and the upload glob already
covers them. A pfSense build failure therefore holds a release the way
a FreeBSD build failure does, which is what a release asset means; on
every other ref the pfsense job's output stays a 30-day artifact.

Not covered by the evidence: physical appliances and CE 2.9.0.

.github/workflows/package-freebsd.yml

@@ -229,15 +229,15 @@ jobs:
 
   pfsense:
     name: Build and check the pfSense package (x86_64)
-    # A job of its own, and deliberately NOT a dependency of `release`. A
-    # pfSense-only failure — a new key in the common dns: block, a
-    # dependency that stops linking statically, a checker regression — reds
-    # this check and nothing else; it can never hide behind the FreeBSD
-    # job's result, and it cannot block the FreeBSD release asset. The
-    # pfSense package is therefore never a release asset. It is published
-    # here as a workflow artifact (30-day retention) for anyone to test,
-    # until someone has installed it on a real pfSense box; see
-    # packaging/pfsense/README.md.
+    # A job of its own, so a pfSense-only failure — a new key in the common
+    # dns: block, a dependency that stops linking statically, a checker
+    # regression — reds this check by name and can never hide behind the
+    # FreeBSD job's result. `release` needs both jobs: the packages this
+    # job builds are release assets next to the FreeBSD one, after being run
+    # on pfSense Plus 26.03.1 and 26.07 (see packaging/pfsense/README.md),
+    # so a pfSense failure holds the release the way a FreeBSD failure
+    # does. On every other ref the artifact is kept 30 days for anyone to
+    # test.
     #
     # This VM is FreeBSD 15.1. One build yields static FreeBSD 15 binaries,
     # packaged twice: as FreeBSD:15:amd64 for pfSense CE 2.8.1, and relabelled
@@ -357,7 +357,7 @@ jobs:
   release:
     name: Publish FreeBSD assets to GitHub Release
     runs-on: ubuntu-latest
-    needs: build
+    needs: [build, pfsense]
     if: startsWith(github.ref, 'refs/tags/')
     permissions:
       contents: write
@@ -366,28 +366,36 @@ jobs:
       - name: Download FreeBSD artifacts
         uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8
         with:
-          # Only the FreeBSD artifact. Without a pattern this action downloads
-          # every artifact in the run — including the pfSense package from the
-          # `pfsense` job, which is a workflow artifact by design and must never
-          # reach a release. `needs` only orders jobs; it does not scope this.
+          # One named pattern per job: without a pattern this action downloads
+          # every artifact in the run, and `needs` only orders jobs; it does
+          # not scope this.
           pattern: fips_*_x86_64_freebsd
           path: dist
           merge-multiple: true
 
+      - name: Download pfSense artifacts
+        uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8
+        with:
+          pattern: fips_*_x86_64_pfsense
+          path: dist
+          merge-multiple: true
+
       - name: Validate .pkg bytes before publishing
         shell: bash
         run: |
           set -euo pipefail
           cd dist
 
-          # The pfSense package is never a release asset (see the `pfsense`
-          # job). The download step is scoped to the FreeBSD artifact; this
-          # keeps the rule if that artifact is ever renamed or a new one added.
-          if compgen -G '*-pfsense-*' >/dev/null; then
-            echo "FAIL: a pfSense package reached the release stage; it must stay a workflow artifact:" >&2
-            ls -la ./*-pfsense-* >&2 || true
-            exit 1
-          fi
+          # Three packages are expected: the FreeBSD one and the two pfSense
+          # ones (each job wrote the sidecars inside its own VM). Missing one
+          # is a failure, not a smaller release.
+          for want in '*-freebsd-*.pkg' '*-pfsense-ce2.8-amd64.pkg' '*-pfsense-ce2.9-plus26-amd64.pkg'; do
+            if ! compgen -G "$want" >/dev/null; then
+              echo "FAIL: no package matching $want was downloaded" >&2
+              ls -la . >&2 || true
+              exit 1
+            fi
+          done
 
           pkgs=$(find . -maxdepth 1 -type f -name '*.pkg' | LC_ALL=C sort)
           if [[ -z "$pkgs" ]]; then

CHANGELOG.md

@@ -159,9 +159,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   run through the boot script's start, re-entrant start, a forced
   `newsyslog` rotation, restart, stop and `pkg delete`
   (`testing/pfsense-install-smoke.sh`, also the first thing to run on a
-  real box), and published as a workflow artifact, not
-  attached to a release, until it has been installed on a real pfSense
-  box. CI produces both Intel packages from that one FreeBSD 15.1 build:
+  real box), and attached to each release next to the FreeBSD package,
+  after being run on pfSense Plus 26.03.1 and 26.07 with mesh traffic
+  between them. CI produces both Intel packages from that one FreeBSD 15.1 build:
   the CE 2.8.1 (`FreeBSD:15:amd64`) package, and the CE 2.9 / Plus 26.x
   (`FreeBSD:16:amd64`) package as the same static binaries relabelled,
   which is the direction FreeBSD's binary compatibility supports and has

README.md

@@ -191,10 +191,9 @@ pfSense has no column of its own: it is the FreeBSD package with
 pfSense's boot script and DNS Resolver integration, under
 [`packaging/pfsense/`](packaging/pfsense/). CI builds it for CE 2.8.1
 (FreeBSD 15) and for CE 2.9.0 and Plus 26.x on x86_64 (FreeBSD 16, the
-same static binaries relabelled), and keeps it as a 30-day workflow
-artifact rather than a release asset until it has been proven on a real
-appliance; ARM is build-it-yourself. What each package has been run on is
-in that directory's README.
+same static binaries relabelled) and attaches both to each release next
+to the FreeBSD package; ARM is build-it-yourself. What each package has
+been run on is in that directory's README.
 
 Five of these columns are Linux: Debian/Ubuntu, Arch, NixOS, OpenWrt
 and Android. Linux is not one target. Debian, Ubuntu, Arch and NixOS

packaging/pfsense/README.md

@@ -118,14 +118,17 @@ difference decides which may be published:
 
 | Artifact | linkage | toolchain pin | CI |
 |---|---|---|---|
-| `…-pfsense-ce2.8-amd64.pkg` | static | honoured | built, checked, install-smoked; workflow artifact |
-| `…-pfsense-ce2.9-plus26-amd64.pkg` | static | honoured | built (the CE 2.8 binaries, relabelled), checked; workflow artifact |
+| `…-pfsense-ce2.8-amd64.pkg` | static | honoured | built, checked, install-smoked; release asset |
+| `…-pfsense-ce2.9-plus26-amd64.pkg` | static | honoured | built (the CE 2.8 binaries, relabelled), checked; release asset |
 | `…-pfsense-plus26-aarch64.pkg` | dynamic | **not** honoured | not built — build it yourself |
 
-No pfSense package is attached to a release. It is built and checked in
-its own CI job (so a pfSense-only failure reds that job without blocking
-the FreeBSD asset) and kept as a 30-day workflow artifact, until one has
-been installed on a real pfSense box. "Install-smoked" means
+Both Intel packages are release assets: each tagged release carries
+them next to the FreeBSD package, with their SHA-256 in
+`checksums-freebsd.txt`. They are built and checked in their own CI job,
+so a pfSense-only failure reds that job by name, and the release job
+needs it, so such a failure holds the release rather than shipping
+without them. On every other ref the job's output is a 30-day workflow
+artifact for anyone to test. "Install-smoked" means
 `testing/pfsense-install-smoke.sh` ran it on the plain FreeBSD VM of the
 same major: `pkg add`, the boot script's start, re-entrant start, restart
 and stop with the real daemon answering `fipsctl` and DNS queries, a