ci(desktop): add signed macOS canary build

[baxen]

Why

Testers need a Gatekeeper-valid build of current main without creating a release or updating existing installations.

What

• Add a manual, main-only Apple Silicon workflow that signs and notarizes a DMG
• Store the DMG as an unpublished seven-day Actions artifact with read-only repository permissions
• Add a release-safety contract that requires workflow_dispatch to remain the only trigger
• Document canary build/download usage and the artifact's public-repository visibility

Risk Assessment

Low — the workflow is manual-only and cannot create tags, GitHub Releases, or auto-updater assets. It does use the production Apple signing identity for explicitly requested canary builds; any signed-in GitHub user can download the artifact during its seven-day lifetime.

References

• scripts/test-signed-canary-contract.sh
• scripts/test-release-ref-contract.sh

---

Update Jul 22, 14:32: Addressed review feedback

• Replaced the inaccurate "private artifact" wording with explicit visibility semantics
• Tightened the contract from a partial trigger denylist to an only-workflow_dispatch assertion

Generated with Codex

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d29bb97ecb

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep signed canaries out of public artifacts

Because block/buzz is the OSS/public source repo, uploading the signed DMG with actions/upload-artifact does not make it private: GitHub's artifact docs say workflow artifacts can be downloaded by signed-in users with repository read access, which in a public repo is effectively any GitHub user. That exposes production-signed -test builds for the full retention window instead of limiting them to explicit testers, so this should use a genuinely access-controlled store or environment rather than a workflow artifact.

Useful? React with 👍 / 👎.

[wesbillman]

Reviewed the workflow against release.yml and the release-safety contracts; ran both contract scripts locally at the PR head (d29bb97ec) — release ref contract passed / signed canary contract passed — and confirmed the branch contains current main.

What holds up well:

• Publishing surface is genuinely zero: contents: read at both workflow and job level, no gh release, no TAURI_SIGNING_PRIVATE_KEY, createUpdaterArtifacts: false, and the new contract test in scripts/test-signed-canary-contract.sh is wired into CI via test-release-ref-contract.sh, so regressions fail ci.yml.
• The -test.<run> prerelease version derivation sorts below the next real patch release under semver, so even a stray DMG can't masquerade as newer than a real release — and there's no updater artifact to feed the updater anyway.
• Build steps faithfully mirror release.yml (mesh-llm rev via tomllib, llama cache keying, DMG text-size, entitlements staged to ${RUNNER_TEMP}/entitlements.plist for the codesign helper), plus it adds verify-macos-entitlements.sh to the post-sign checks.
• Actions pinned by SHA, persist-credentials: false, zizmor green.
• The RELEASING.md claim that the Release workflow "cannot build from main" is accurate — verify-release-ref.sh gates both the setup and build jobs on refs/tags/v<version>.

Two things worth a look:

1. "Private ... Actions artifact" oversells it. block/buzz is a public repo; workflow-run artifacts on public repos are downloadable by any logged-in GitHub user (UI and API) for the retention window. So this ships a Gatekeeper-valid, production-identity-signed DMG that anyone can grab for 7 days. Probably acceptable — release DMGs are public anyway — but the PR body and RELEASING.md ("private Actions artifact") should say "short-lived" or "unpublished" rather than "private", so nobody relies on a confidentiality property that doesn't exist.

2. The manual-only guard in the contract test has trigger gaps. grep -qE '^ (push|pull_request|schedule):' won't catch pull_request_target:, workflow_call:, workflow_run:, or repository_dispatch:. Suggest widening the alternation (or inverting: assert the on: block contains only workflow_dispatch). Cheap change, closes the loophole the test exists to guard.

Nit: minimumSystemVersion: 10.15 on an arm64-only build is a no-op (Apple Silicon floor is 11.0) — harmless, mirrors the release config.

Verdict: LGTM once the "private" wording is fixed; item 2 is a nice-to-have hardening.