Correct the release documents the readiness pass found wrong

The closing code fence in the release notes carried an info string, so under
CommonMark it was not a closer and the block ran to the end of the file.
Rendered through GitHub's own markdown endpoint the published body stopped
emitting headings after "Upgrade notes" and ended inside a code block, so
the download section, the changelog and security links and the contributor
credits all became preformatted text. Rendering the corrected file the same
way returns all seven headings and a working release link. A lint fix had
rewritten both fences rather than only the opening one.

The post-upgrade instruction named a subcommand that does not exist: it said
to run fipsctl status, which exits 2, where the command is fipsctl show
status. That instruction is aimed at exactly the users this release exists
for.

Several claims were broader than the tree supports, and each is narrowed to
what is true. The two discovery fixes carry no platform gating, so the notes
no longer tell macOS, Windows, FreeBSD and OpenWrt users that nothing
changed for them, and no longer say the release contains no behavioral
change. The supported-distribution paragraph now covers the .deb and the
tarball rather than all Linux artifacts, since Arch and NixOS build from
source and OpenWrt is a musl target that does not depend on the glibc floor.
The install-test sentence says x86_64, because the arm64 package is
install-tested by nothing. The changelog no longer claims every producer
runs the floor check, since the deprecated host-build targets do not.

The counter guidance was wrong about which counter moves, the objdump line
prints the symbol beside the version, and the two relative links in the
notes resolve inside the repository but 404 in a release body, so they are
absolute now. That last change also makes the root mirror byte-identical to
the versioned copy for the first time.

The FreeBSD install line takes a concrete filename again: a placeholder is
not pasteable, which is the whole point of an install instruction.
This commit is contained in:
Johnathan Corgan
2026-09-06 20:20:56 +00:00
parent f0ee81ec7c
commit 30a283907b
6 changed files with 65 additions and 46 deletions
+4 -2
View File
@@ -57,9 +57,11 @@ Nothing yet. Everything previously staged here is folded into
it looked healthy while the daemon was dead. No source code caused this and
none was changed. The Linux artifacts are now built in a container pinned to
the oldest supported distribution, declared with the floor in
`packaging/build-floor.env`, and every producer runs
`packaging/build-floor.env`, and every producer on the release path runs
`testing/check-glibc-floor.sh` on what it made, so a package or a tarball that
would not load fails the build rather than reaching a user. The declared
would not load fails the build rather than reaching a user. The deprecated
host-build targets in `packaging/Makefile` are not on that path and are not
floor-checked. The declared
dependency is derived from the binaries instead of hand-written, so it states
the floor it was built against.
+9 -5
View File
@@ -194,9 +194,10 @@ takes `fips` from the AUR, and NixOS uses the Nix flake described
below. **Only the `.deb` is exercised by an install test**, by the
`deb-install` suite across debian12, debian13, ubuntu22, ubuntu24 and
ubuntu26; neither the AUR package nor the flake is. That suite runs on
every push and pull request, against a `.deb` built by the same pinned
container as the released one. It does not run at a tag: no workflow
installs the published artifact, so the released package is checked by
every push and pull request, on x86_64, against a `.deb` built by the same
pinned container as the released one. It does not run at a tag, and the
arm64 package is install-tested by nothing: no workflow installs a published
artifact, so the released packages are checked by
hand. OpenWrt is a musl
target rather than glibc, and it takes an `.ipk` on 24.x and earlier or
an `.apk` on 25 and later; both carry the `fips-mesh-setup` and
@@ -308,12 +309,15 @@ that makes the Linux packages install and run on Debian 12 and Ubuntu
22.04, where every artifact from v0.3.0 through v0.5.0 installed and
then could not start.
[v0.5.0](https://github.com/jmcorgan/fips/releases/tag/v0.5.0) was the
last feature release, so how much of it is new to you depends on which
version you are upgrading from. The core
last feature release, so how much of that release is new to you depends on
which version you are upgrading from. The core
protocol
works end-to-end over UDP, TCP, Ethernet, Tor, Nym, and Bluetooth on a
global, public test mesh of thousands of nodes.
v0.5.1 is a packaging fix and carries two discovery fixes; the feature
content below is v0.5.0's.
v0.5.0 is a platform-and-lifecycle release. It adds FreeBSD as a
packaged platform (x86_64 only), OpenWrt setup helpers for an 802.11s
mesh between routers (`fips-mesh-setup`) and for the open `!FIPS` client
+21 -16
View File
@@ -22,9 +22,9 @@ contribution. There is no wire format change and no new configuration.
it.
- **Any other Linux: upgrade at your convenience.** Your daemon was
running, and you gain the two discovery fixes.
- **macOS, Windows, FreeBSD and OpenWrt: nothing changed for you.** The
defect was in how the Linux artifacts were built. Those artifacts are
rebuilt from the same source and are otherwise as v0.5.0 shipped them.
- **macOS, Windows, FreeBSD and OpenWrt: the packaging defect never
affected you**, since it was in how the Linux artifacts were built. You
do get the two discovery fixes, which are not gated by platform.
- **From source: you were never affected.** A binary you built runs
against the C library you built it on.
@@ -54,9 +54,10 @@ an older C library. **`fipsctl` was unaffected**, which is why an
install checked by running a command looked healthy while the daemon was
dead.
**No source code caused this and none was changed.** The defect was in
the build environment, and the release contains no behavioral change to
the daemon.
**No source code caused the packaging defect and none was changed to fix
it.** The defect was in the build environment. The two discovery fixes
below are this release's only behavioral change, and they are unrelated to
it.
**Why the declared dependency did not stop it.** The `.deb` said it
needed `libc6` with no version, which every glibc satisfies. So a
@@ -126,9 +127,10 @@ It now has its own rejection reason and counter, `req_own_loopback`,
shown in `fipstop` as "Own Loopback". `req_duplicate` returns to meaning
only what it says.
**If you watch these counters**, expect `req_duplicate` to drop and a
new non-zero `Own Loopback` to appear. That is the same traffic,
correctly attributed, not a new fault.
**If you watch these counters**, expect a new non-zero `Own Loopback` to
appear on a node that originates lookups. That is traffic that was
previously counted elsewhere or not at all, correctly attributed, rather
than a new fault.
## Compatibility
@@ -145,18 +147,19 @@ The library surface is unchanged. Configuration is unchanged.
**Package upgrade, Debian and Ubuntu.** The usual upgrade replaces the
binaries and restarts the service. On Debian 12 and Ubuntu 22.04 the
daemon will start for the first time, so this is a first start rather
than a restart: check `fipsctl status` afterwards and expect to see peer
establishment, not a resumed session.
than a restart: check `fipsctl show status` afterwards and expect to see
peer establishment, not a resumed session.
**Check what you actually have.** If you want to confirm the floor of an
installed binary rather than trust the version string:
```text
objdump -T /usr/bin/fips | grep GLIBC_ | sed 's/.*GLIBC_//' | sort -uV | tail -1
```text
```
An artifact from this release reports 2.34. One from v0.5.0 or earlier
reports 2.39.
An artifact from this release prints `2.34) __libc_start_main`. One from
v0.5.0 or earlier prints `2.39) pidfd_spawnp`, which names the symbol that
caused this.
**Rolling upgrade.** No coordination is needed. Upgrade nodes in any
order.
@@ -182,9 +185,11 @@ There is no Android daemon artifact. Android is supported as an embedded
crate.
The full per-commit changelog lives in
[`CHANGELOG.md`](CHANGELOG.md). Issues and discussion at
[`CHANGELOG.md`](https://github.com/jmcorgan/fips/blob/v0.5.1/CHANGELOG.md).
Issues and discussion at
[github.com/jmcorgan/fips](https://github.com/jmcorgan/fips). Security
reports have a private channel; see [`SECURITY.md`](SECURITY.md).
reports have a private channel; see
[`SECURITY.md`](https://github.com/jmcorgan/fips/blob/v0.5.1/SECURITY.md).
## Contributors
+9 -6
View File
@@ -66,12 +66,15 @@ per-platform installer:
- Windows: `.zip` with service-install scripts
- Generic systemd Linux: `.tar.gz` with an `install.sh` script
FIPS supports every version of a supported distribution that its vendor
still supports for free: currently Ubuntu 22.04, Debian 12, Ubuntu 24.04,
Debian 13 and Ubuntu 26.04. The Linux binaries are built in a container
pinned to the oldest of those, so they run on all of them. The glibc floor
that follows is declared in `packaging/build-floor.env` and is enforced on
every artifact by `testing/check-glibc-floor.sh`.
The `.deb` and the systemd tarball support every version of a glibc
distribution that its vendor still supports for free: currently Ubuntu
22.04, Debian 12, Ubuntu 24.04, Debian 13 and Ubuntu 26.04. Those binaries
are built in a container pinned to the oldest of them, so they run on all
five, and the glibc floor that follows is declared in
`packaging/build-floor.env` and checked by `testing/check-glibc-floor.sh` on
what the release workflow produces. Arch and NixOS build from source on your
own machine, and OpenWrt is a musl target rather than glibc, so none of them
depends on that floor.
See the [project README's Quick start section](../README.md#quick-start)
for download links and per-platform invocations.
+21 -16
View File
@@ -22,9 +22,9 @@ contribution. There is no wire format change and no new configuration.
it.
- **Any other Linux: upgrade at your convenience.** Your daemon was
running, and you gain the two discovery fixes.
- **macOS, Windows, FreeBSD and OpenWrt: nothing changed for you.** The
defect was in how the Linux artifacts were built. Those artifacts are
rebuilt from the same source and are otherwise as v0.5.0 shipped them.
- **macOS, Windows, FreeBSD and OpenWrt: the packaging defect never
affected you**, since it was in how the Linux artifacts were built. You
do get the two discovery fixes, which are not gated by platform.
- **From source: you were never affected.** A binary you built runs
against the C library you built it on.
@@ -54,9 +54,10 @@ an older C library. **`fipsctl` was unaffected**, which is why an
install checked by running a command looked healthy while the daemon was
dead.
**No source code caused this and none was changed.** The defect was in
the build environment, and the release contains no behavioral change to
the daemon.
**No source code caused the packaging defect and none was changed to fix
it.** The defect was in the build environment. The two discovery fixes
below are this release's only behavioral change, and they are unrelated to
it.
**Why the declared dependency did not stop it.** The `.deb` said it
needed `libc6` with no version, which every glibc satisfies. So a
@@ -126,9 +127,10 @@ It now has its own rejection reason and counter, `req_own_loopback`,
shown in `fipstop` as "Own Loopback". `req_duplicate` returns to meaning
only what it says.
**If you watch these counters**, expect `req_duplicate` to drop and a
new non-zero `Own Loopback` to appear. That is the same traffic,
correctly attributed, not a new fault.
**If you watch these counters**, expect a new non-zero `Own Loopback` to
appear on a node that originates lookups. That is traffic that was
previously counted elsewhere or not at all, correctly attributed, rather
than a new fault.
## Compatibility
@@ -145,18 +147,19 @@ The library surface is unchanged. Configuration is unchanged.
**Package upgrade, Debian and Ubuntu.** The usual upgrade replaces the
binaries and restarts the service. On Debian 12 and Ubuntu 22.04 the
daemon will start for the first time, so this is a first start rather
than a restart: check `fipsctl status` afterwards and expect to see peer
establishment, not a resumed session.
than a restart: check `fipsctl show status` afterwards and expect to see
peer establishment, not a resumed session.
**Check what you actually have.** If you want to confirm the floor of an
installed binary rather than trust the version string:
```text
objdump -T /usr/bin/fips | grep GLIBC_ | sed 's/.*GLIBC_//' | sort -uV | tail -1
```text
```
An artifact from this release reports 2.34. One from v0.5.0 or earlier
reports 2.39.
An artifact from this release prints `2.34) __libc_start_main`. One from
v0.5.0 or earlier prints `2.39) pidfd_spawnp`, which names the symbol that
caused this.
**Rolling upgrade.** No coordination is needed. Upgrade nodes in any
order.
@@ -182,9 +185,11 @@ There is no Android daemon artifact. Android is supported as an embedded
crate.
The full per-commit changelog lives in
[`CHANGELOG.md`](../../CHANGELOG.md). Issues and discussion at
[`CHANGELOG.md`](https://github.com/jmcorgan/fips/blob/v0.5.1/CHANGELOG.md).
Issues and discussion at
[github.com/jmcorgan/fips](https://github.com/jmcorgan/fips). Security
reports have a private channel; see [`SECURITY.md`](../../SECURITY.md).
reports have a private channel; see
[`SECURITY.md`](https://github.com/jmcorgan/fips/blob/v0.5.1/SECURITY.md).
## Contributors
+1 -1
View File
@@ -24,7 +24,7 @@ Output: `deploy/fips-<version>-freebsd-<arch>.pkg` (e.g.
## Install
```sh
pkg add ./deploy/fips-<version>-freebsd-amd64.pkg
pkg add ./deploy/fips-0.5.1-freebsd-amd64.pkg
# post-install seeds this from the sample if absent, at mode 0600
vi /usr/local/etc/fips/fips.yaml
sysrc fips_enable=YES fips_dns_enable=YES