ci: add opt-in fork-friendly release ops (signing, publishing, fork sync)

[arcaven]

Offers back the release-ops pipeline the ArcavenAE fork has been running in production since 2026-07-15. Everything is inert by default: with no repository variables set, every job either skips at scheduling time or never triggers, and CI is unaffected — no Apple Developer account, secrets, or tap repo are required to host these files. The design is ported from jira-cli's fork-friendly release-ops (docs/specs/fork-friendly-release-ops.md there), where the same pattern already lives upstream.

What this adds

File	Purpose	Inert unless
.github/workflows/sign-and-publish.yml	Sign + notarize macOS binaries on five channels (develop push → wirerust-a, v*-dev.* → wirerust-d, v*-beta.* → wirerust-b, v*-rc.* → wirerust-rc, stable v* → wirerust), publish to a Homebrew tap	vars.SIGNING_ENABLED == 'true' (+ vars.HOMEBREW_TAP_REPO for tap jobs)
.github/workflows/backfill-release.yml	Build + release an existing tag that has no GitHub Release; optional sign/publish	manual workflow_dispatch only; sign/tap jobs var-gated
.github/workflows/sync-upstream.yml	Scheduled fork→upstream merge (main/develop/factory-artifacts) with protected-file auto-resolution	vars.SYNC_UPSTREAM_REPO set (forks only)
.github/workflows/signing-guard.yml	Actively runs on PRs/pushes touching workflows: YAML-structure-aware CWE-77 scanner for inline ${{ }} expansions in secret-bearing jobs (scripts/check-signing-workflow-injection.sh, includes --self-test negative fixture)	n/a — read-only lint, no secrets, python3+PyYAML are runner-preinstalled
.github/local-workflows.txt	Registry of files the fork sync auto-resolves "ours" on conflict	read only by sync-upstream
Formula/wirerust{,-a,-b,-d,-rc}.rb	Homebrew formula templates (placeholders sed'd at publish); parallel channel installs (wirerust + wirerust-a coexist)	read only by the publish jobs
packaging/Info.plist, scripts/create-{app,dmg,pkg}.sh	macOS .app/.dmg/.pkg packaging helpers	invoked only by sign jobs

Notes for review

• All uses: are 40-char SHA-pinned and pass the existing action-pin gate. dtolnay/rust-toolchain is pinned to a master SHA with an explicit toolchain: stable input rather than a versioned-branch snapshot — the versioned-branch SHAs hardcode their toolchain and silently ignore the toolchain: input (we hit this live: two failed runs before the fix; wirerust needs 1.91 and has no rust-toolchain.toml to mask it, since this repo intentionally tracks rolling stable).
• Security posture: run-blocks in secret-bearing jobs env-bind all context expressions (CWE-77), alpha tags are reserved atomically via the GitHub API (no TOCTOU), verification steps use set -eo pipefail + mktemp/trap. The signing-guard workflow enforces the env-binding rule structurally and fails closed.
• Bundle identifier is com.arcavenae.wirerust in packaging/Info.plist + create-pkg.sh — per the jira-cli convention this reflects the first signing fork; a different signing fork overrides it to match its own Apple team. Happy to change if you'd prefer a placeholder.
• Formula descriptions stay ≤ 80 chars including channel suffixes (Homebrew's brew audit desc cap); the templates carry the audit rules as comments.
• The CHANGELOG gate is untouched: this PR modifies only .github/, Formula/, packaging/, scripts/.

Verified in production (ArcavenAE/wirerust)

• Alpha channel: signed + notarized + stapled binaries/pkg/dmg published, brew install arcavenae/tap/wirerust-a verified (Developer ID chain + hardened runtime).
• Stable channel: v0.12.1 backfilled, signed, brew install arcavenae/tap/wirerust verified; parallel install with wirerust-a confirmed.
• Sync: scheduled merges green across main/develop/factory-artifacts.

If merged as-is, the fork and upstream copies are byte-identical, so future scheduled syncs remain conflict-free and the local-workflows.txt entries become pure insurance. mise users also get mise use github:Zious11/wirerust@latest for free from the release assets.

[Zious11]

Thank you for this contribution — the fork-friendly release-ops design is genuinely well-engineered. We confirmed it is opt-in and inert on the base repo today (0 repository variables set), the workflows follow least-privilege permissions, the injection guard's structural scope detection plus its negative-fixture self-test are a solid pattern, and the atomic tag reservation approach is sound. We'd like to get this merged, but we need the items below addressed first.

Blocking (please fix before merge)

1. Homebrew formulae have no OS guard
Formula/*.rb (around line 9) branches only on Hardware::CPU.arm?, with no OS.mac? check or depends_on :macos. On Linux, brew install falls through to the else branch and downloads the *-darwin-* Mach-O binary, which will silently fail to run. Please add depends_on :macos, or on_macos/on_linux blocks with an explicit "unsupported on Linux" message — these formulae don't currently ship a Linux artifact.

2. Unknown-channel tags produce misleading release notes
In sign-and-publish.yml, a tag whose suffix doesn't match -dev./-rc./-beta. is classified channel=unknown. The stable-homebrew job's if: correctly skips publishing in that case, but the "Update release title and notes" case statement's default branch (*) FORMULA="wirerust") still advertises brew install .../wirerust for a version that was never pushed to that formula. Please default the binary/install line to "download below" for the unknown-channel case.

3. Injection-guard scope gap (CWE-94/CWE-78)
sync-upstream.yml's "Report unresolved conflict" step inlines ${{ steps.merge.outputs.files }} directly into a run: body, inside a job that holds contents: write plus secrets.SYNC_UPSTREAM_SSH_KEY. That job meets the injection guard's own in-scope criteria, but check-signing-workflow-injection.sh only scans sign-and-publish.yml and backfill-release.yml, so it misses this case. Please: (a) env:-bind the value (e.g. CONFLICTED_FILES: ${{ steps.merge.outputs.files }}, then reference "$CONFLICTED_FILES"), and (b) extend the guard's scanned-file list — or better, have it self-discover workflows meeting its in-scope criteria — so CI catches this class going forward. (To be clear: this is only exploitable via a compromised operator-configured upstream, not a base-repo risk — but it does contradict the PR's stated "all context expressions env-bound" posture.)

4. Dead spec-doc references
There are 7 references across 6 files citing docs/specs/fork-friendly-release-ops.md, which doesn't exist in this repo — it only lives in ArcavenAE/jira-cli. Please either port the spec into wirerust or repoint the comments to a correct external permalink.

Strongly recommended before merge (security-sensitive duplication)

5. Roughly 450 lines of keychain-import → codesign → notarize → verify → checksum logic are triplicated across alpha-sign/stable-sign in sign-and-publish.yml and the backfill sign job. Please extract this into a composite action or a shared scripts/sign-and-notarize.sh — drift has already crept in (inconsistent set -euo pipefail). The parallel Homebrew tap-update block is likewise duplicated 3x with the same drift risk; please factor it into scripts/update-homebrew-formula.sh.

Fast-follow (not merge-blocking; fork-operator-only, inert on the base repo)

6. sync-upstream.yml merges upstream with no commit-signature verification and pushes directly (no PR/CI gate) to protected branches, silently "ours-wins" shadowing the signing/release files with no drift report (CWE-829/494). Consider opening a PR instead of a direct push, git verify-commit/signed-tag checks before merge, and a scheduled diff of the local-workflows set vs. upstream that warns on divergence.

7. Nothing validates that signing secrets are actually populated, nor that the release environment has protection rules configured (CWE-280/1188). Consider adding secret-presence preflight asserts and a verify-signing-setup dispatch job.

Minor

• Release-notes NOTES= continuation lines carry literal 10-space indentation, which GitHub renders as a code block — left-align them or build the notes with printf.
• sync-upstream.yml is missing a trailing newline.
• egress-policy: audit (log-only) is set on jobs holding signing certs — consider block with an explicit allowlist.
• dtolnay/rust-toolchain is pinned here to a different SHA than open PR #451 pins repo-wide — whichever PR merges second should reconcile onto the other's SHA.

Thanks again for the care put into this — the security-conscious design (opt-in, least-privilege, self-testing injection guard) is exactly the kind of contribution we want more of. Looking forward to a follow-up revision.

https://claude.ai/code/session_01EQAaPvh9fwaG31jmkPicKW

[arcaven]

Revision pushed as 3643b0a9. All four blocking items, the duplication item, and the four minors. Every claim below has the command that produced it, since a few of them are counts.

1. OS guard. All five formulae now declare depends_on :macos. While in there I also dropped the stable formula's version line: its tag is v<version>, so brew scans the same value from the URL and brew audit --strict rejects the duplicate. The four prerelease templates keep theirs, because their tags do not scan to the declared value. Verified by rendering all five with realistic tags into a scratch tap:

$ brew audit --strict arcaven-scratch/wr/wirerust      # and -a, -b, -d, -rc
(clean)
$ brew style arcaven-scratch/wr/wirerust               # and the other four
1 file inspected, no offenses detected

2. Unknown channel. The default case arm now leaves FORMULA empty, so BINARY_LINE stays download below. The release title falls back to the bare project name rather than to a formula that was never updated.

3. Guard scope. sync-upstream.yml's conflict report binds steps.merge.outputs.files through env:, and every other context in that workflow's run: bodies is bound too, so the stated posture now holds there. The guard self-discovers rather than reading a list: it scans every workflow in .github/workflows/ against its existing structural criteria, keeping sign-and-publish.yml and backfill-release.yml as required files whose zero-in-scope result is still the broken-detection sentinel. A discovered workflow scoring zero is the normal case, not a sentinel.

Summary: scanned 46 run-blocks across 2 required + 3 discovered in-scope file(s)
  In-scope: sync-upstream.yml sync(uses secrets.*), ci.yml semantic-pr, release.yml release
0 inline high-risk expansion(s) flagged

Negative control, because a guard that has never failed has not been tested. Reintroducing the inline expression:

FAILURE: inline high-risk context expansions found in run: script bodies:
  [sync-upstream.yml] job=sync, step='Report unresolved conflict': ${{ steps.merge.outputs.files }}

4. Dead references. All 7 now point at a commit-pinned permalink to the external design doc. Porting the spec would have imported 432 lines of another project's document, most of it jira-cli specific, so I took the permalink option you offered. Both cited section headings were checked to exist at that commit.

$ git grep -c 'docs/specs/fork-friendly-release-ops.md' HEAD -- .github scripts   # 7
$ git grep 'docs/specs/...' HEAD | grep -vc 'jira-cli/blob'                       # 0

5. Deduplication. You were right that drift had already started. The stable-sign block and the backfill sign job were byte-identical (diff returns nothing), and alpha-sign differed only by the binary prefix and one comment. Both are now scripts/sign-and-notarize.sh and scripts/update-homebrew-formula.sh, with set -euo pipefail in each. Workflows lose 437 lines and gain 107; the scripts add 266.

One deviation from your suggestion worth flagging. The signing script takes subcommands (import-certs, sign-binaries, package, notarize, verify, checksums) rather than running end to end, so each phase stays its own workflow step and its secrets stay scoped to that step. A single entry point or composite action would put the notarization credentials in scope for signing and the signing identity in scope for notarization, which trades away more than the duplication is worth. If you would rather have one composite action anyway, say so and I will change it.

Two checks on the refactor, since this is the part where a silent mistake is expensive: the step sequence is identical before and after in both workflows, and per-step env: keys are identical apart from one added COMMIT_SHA. So no secret gained or lost scope. shellcheck -S warning is clean on both new scripts.

Minors. Release notes are built with printf so continuation lines carry no YAML indentation. sync-upstream.yml has its trailing newline. The dtolnay/rust-toolchain pin moves onto the SHA #451 uses (2c7215f1, a real commit on that repo's master), so whichever of the two lands first, the other needs no reconciliation.

Not done: egress-policy: block. Block mode grades against a per-repo allowlist, and these jobs have only ever run in audit mode, so there is no detections history to derive one from. Turning it on blind means the signing jobs start failing on an unrelated day for an endpoint nobody wrote down. Happy to do it as a follow-up once a few audit-mode runs have produced the endpoint list, if you want it.

Fast-follows 6 and 7 I have left alone as you scoped them, but I am glad to take either in a separate PR rather than growing this one.

https://claude.ai/code/session_01YV58wMepvhR6qNYZhwPJkV