fix: the three things that must be true before v0.7.0 is tagged or its advisories published

[rainmanjam]

Batch A from the pre-tag sweep (docs/notes/pre-tag-sweep-v0.7.0.md). Small changes, each blocking something.

1. The give-up line leaked the stream key — and GHSA-7jqx says it doesn't

The advisory claims "The supervisor scrubs the process exited line." It does. #311 fixed that line and left this one below it in the same function, on the same msg:

:669   p.log.Warn("process exited",        "err", p.scrub(msg), …)   // scrubbed
:703   p.log.Error("giving up on process", …, "err", msg)            // NOT scrubbed

msg is runOnce's error, carrying FFmpeg's stderr and with it the publish URL and its key.

This is the worse of the two to leak on. It fires only after MaxRestarts consecutive failures — after a destination has been refused over and over, which is exactly when an operator stops watching and starts copying server.log into an issue. The retry line got attention because it fires often; this one fires when someone is about to ask a stranger for help.

So this gates the advisories, not just the tag. Publishing GHSA-7jqx before this landed would have claimed a fix that was half done.

The existing test couldn't see it — it pins a supervisor that retries forever, so the give-up arm never runs. The new test needs AutoRestart + low MaxRestarts + short backoff to reach the branch.

Mutation: reverting to "err", msg fails the new test and leaves the old one passing. That second half is the point.

2. The secret.key guard refused upgrades it should have allowed

tar tzf … | grep -q under set -o pipefail: grep -q exits on first match → tar takes SIGPIPE → pipeline returns 141 → if ! inverts it into "the file is missing."

The mechanism is not what the sweep reported. It attributed this to inode order. It's the pipe buffer, measured in debian:bookworm-slim:

     0 extra files: OLD=pass     NEW=pass
    10 extra files: OLD=pass     NEW=pass
   200 extra files: OLD=pass     NEW=pass
  2000 extra files: OLD=REFUSED  NEW=pass

So it is deterministic, not flaky, and would have blocked the upgrade on essentially every install with a real recordings volume. Invisible on macOS (bsdtar exits 0 on SIGPIPE) and acceptance-install.sh only ever exercised the binary-mode script.

Herestrings rather than printf | grep, because printf takes SIGPIPE too — reordering the pipeline would move the bug, not remove it.

This guard was added in #348 to prevent data loss, and could block the upgrade it was written to protect.

3. A failed binaries job left container tags with no release

release.yml had no needs: anywhere. A binaries failure left Docker Hub and GHCR carrying :0.7.0/:latest with no GitHub Release, no checksums, no SBOM.

That splits the install modes: install.sh:729 writes image: <IMAGE>:latest, so docker operators take it immediately while binary installs resolve via releases/latest and stay put. Same tag, two populations, one running an artefact whose SBOM never passed its guard.

4. UPGRADING.md couldn't have warned anyone

No 0.7.0 section, and grep -in 'seal\|encrypt\|secret\.key' returned nothing across 196 lines — for the release that makes secret.key the difference between a restore and a silent outage. It also never mentioned update.sh, steering operators to the hand-rolled procedure instead of the guarded script.

Added the 0.7.0 note, the roll-back warning (0.6.0 reads every destination as having an empty key while still enabled, with no schema version to refuse on), the secret.key check in Rolling back, and a keyUnreadable check in Verifying — because a restore that omits the key file looks completely successful until go-live.

Verification

• Generated both update.sh variants out of their heredocs and syntax-checked them — bash -n install.sh does not check heredoc contents.
• go build ./..., go vet, go test -race ./internal/supervisor.
• actionlint release.yml unchanged at its one pre-existing finding.

Not in this PR

hevc_vaapi (offered and cannot start), capped VBR on NVENC, the advisory text corrections, and the docs sweep. Enhanced Broadcasting is being wired separately.

https://claude.ai/code/session_01HeLrWaDmsNeeNSbHQfEofX

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

This PR addresses several pre-v0.7.0 release blockers: preventing stream-key leakage in supervisor logs, fixing an upgrade guard that could falsely refuse valid backups, ensuring release workflow ordering avoids half-published container tags, and documenting the 0.7.0 secret.key implications for upgrades/restores.

Changes:

• Scrub stream keys on the supervisor “giving up on process” log line and add a regression test covering the give-up path.
• Fix the secret.key guard in the generated update.sh by avoiding tar | grep -q under pipefail.
• Serialize release publication so container images are only published after binaries/SBOM/release assets succeed, and document 0.7.0 upgrade/rollback risks.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
scripts/install.sh	Reworks backup verification logic to avoid SIGPIPE/pipefail false negatives; validates secret.key via captured listing.
internal/supervisor/supervisor.go	Scrubs the “giving up on process” error log to prevent stream key disclosure.
internal/supervisor/redact_test.go	Adds a regression test that reaches the give-up branch and asserts keys are masked (not removed).
docs/UPGRADING.md	Adds 0.7.0-specific guidance on secret.key, rollback hazards, and post-upgrade verification.
docs/notes/pre-tag-sweep-v0.7.0.md	Adds a pre-tag sweep checklist documenting verified blockers and findings.
.github/workflows/release.yml	Ensures image publishing waits for binaries job to complete to avoid half-published releases.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.