Tag v0.7.0 and publish the three GHSA advisories

[rainmanjam]

The release is ready; both steps are public and irreversible, so they are deliberately a human's call.

Order matters. All three advisories carry patched_versions: 0.7.0. Publishing before the tag exists tells every downstream scanner that >= 0.7.0 is remediated while giving operators nothing to install.

1. git tag -a v0.7.0 — annotated and unsigned, matching v0.4.0–v0.6.0.
2. Publish GHSA-7jqx-76vq-hvfc (Medium, 5.5), GHSA-wv59-5xvx-xcj8 (low), GHSA-jqc3-g54q-mh8m (low).
3. Their prose currently says "on main and not yet in a tagged release" — that becomes "fixed in 0.7.0" as part of publishing.

State at time of filing: main green, 166 commits since v0.6.0, CHANGELOG [Unreleased] empty with 90 entries in [0.7.0], OVH acceptance 12/12 (269 checks, 0 failures) on the shipping build.

[rainmanjam]

State refresh — the figures in the body are stale

The body says "166 commits since v0.6.0, CHANGELOG [Unreleased] empty with 90 entries in [0.7.0]". All three have moved. Current state:

	at filing	now
commits since v0.6.0	166	304
[Unreleased]	empty	empty (re-folded in #423)
[0.7.0]	90 entries, dated 2026-08-14	136 entries, dated 2026-08-17
open PRs	—	none

What landed in between: the platform capability expansion (#416), installer poka-yoke (#417, #418), debug mode and three user-facing bug fixes (#420), the debug bundle size cap (#422), the full pre-tag code and security review (#429), and a CI reliability fix (#431).

The pre-tag review is the substantive addition. It ran codex, agy and a nine-lens fan-out over the whole delta with adversarial verification — 39 raw findings, 19 surviving — and every confirmed one is fixed. Nine were credentials that stopped escaping, including one that put plaintext stream keys in the write-ahead log permanently after an interrupted upgrade, and one that printed the SRT passphrase or the whole pull URL into journalctl on every boot.

Those are all in [0.7.0]'s Security section now, so the advisories are not the only security content in this release.

The two steps in this issue are unchanged and still in this order: tag first, then publish, because patched_versions: 0.7.0 tells scanners >= 0.7.0 is remediated and publishing first offers nothing to install.

[rainmanjam]

Release status, 2026-08-18

Landed since this issue was last updated

#451 (merged, 31/31) carried the bulk of the pre-tag work:

• Nine pre-release code/security review fixes, with changelog entries
• TestRefreshKeyTellsKickOperatorsToReconnectRatherThanRetry asserts on a live third-party error body #439 — a test that asserted on a live third party (Options{} resolved to the platforms' real hosts, so it reached id.kick.com and depended on Kick answering 401 today)
• fatal error: found pointer to free object on Windows, and an unsafe.Pointer→uintptr no tool checks #440 — fatal error: found pointer to free object on Windows, plus a GOOS=windows go vet step so the class is checked rather than hoped for
• Installer: five defects, a real install/uninstall CI job, and the "Removing it" docs section that did not exist
• CI reliability: every one of 31 jobs now has a timeout-minutes ceiling (one had none, falling back to GitHub's six hours), and the three genuinely un-retried network installs are retried
• ffmpeg destination encoders leak and accumulate for days after a run exits #448 — three defects, detailed on that issue

Also fixed today: FreeUDPWindow could not reach a free port when the probe landed near 65535 (macOS-only, because Linux's ephemeral range stops at 60999), and a supervisor test budget that sat below the shutdown path's own documented worst case.

Open, and where each sits relative to the tag

#	State	Blocks the tag?
#454	PR open — the #453 loudness-monitor leak	No
#453	Root cause fixed; sibling step still not re-landed	No
#448	Harness causes fixed; non-systemd product leak documented and open	No
#398	Being measured	Yes, by decision
#430	Gated on #398	No
#442, #387, #380, #376, #375	Post-tag	No

What is actually holding the tag

Only #398. The decision taken is that if a file destination genuinely produces an empty recording on FFmpeg 8.1.2 — the version the Dockerfile pins and therefore the version users get — the tag waits for a fix rather than shipping with it documented.

Today's evidence has moved against that being true (9.0.1 passes the case cleanly, and the original bisect was already retracted by its author), but it is not settled, and the suite involved has shown intermittency on identical code. The measurement is a flake rate on a pinned 8.1 build, not a single run.

Still deliberately a human's call

The tag itself and the three GHSA advisories. Nothing above changes that. Worth restating that the advisories are the irreversible half — a tag can be moved, a published advisory cannot be unpublished.

[rainmanjam]

The CHANGELOG blocker is cleared (#487, a147031)

The preconditions in this issue had drifted since it was filed, and one was a real blocker — the CHANGELOG was last updated by b6dac4d (#475) with nine merges landed since, so tagging would have shipped release notes omitting two days of work.

this issue says	was	now
commits since v0.6.0	166	436
[Unreleased]	empty	had 1 entry → empty again
[0.7.0] entries	90	169
[0.7.0] date	2026-08-17	2026-08-21

#487 added entries for #472, #478, #479, #480, #481, #482, #483, #484, #485, #486 and moved the Windows job-object fix out of [Unreleased] into [0.7.0], where it actually ships.

Verified on main just now:

• [Unreleased] — 0 bullets
• v0.7.0 — not yet tagged
• open PRs — none

The remaining sequence, unchanged

Still order-critical, for the reason this issue gives: all three advisories carry patched_versions: 0.7.0, so publishing before the tag exists tells every downstream scanner that >= 0.7.0 is remediated while it does not.

git checkout main && git pull
git tag -a v0.7.0 -m "polyemesis v0.7.0"
git push origin v0.7.0

-a and unsigned matches v0.4.0–v0.6.0 — confirmed, those are annotated tag objects.

Then publish, in order:

advisory	severity	subject
GHSA-7jqx-76vq-hvfc	medium 5.5	stream keys escaping through five paths
GHSA-wv59-5xvx-xcj8	low	unauthenticated /assets/ directory listing
GHSA-jqc3-g54q-mh8m	low	MQTT password in a settings validation error

All three confirmed state=draft, patched_versions=0.7.0. Their prose still says "on main and not yet in a tagged release", which becomes "fixed in 0.7.0" as step 3.

One gate before tagging: main's CI for a147031 was still in progress when this was written. Tag a green main.