fix: sign and notarize macOS release binaries

[steipete]

Direct macOS downloads currently carry only the Go linker's ad-hoc signature and fail Gatekeeper. Move releases to the shared Go CLI workflow pinned at v1.9.0 (f613cbfed2b043159c850c353e7facb8c89833b0), using Peter Steinberger's personal Developer ID policy (Y5PE65HELJ).

The caller maps the existing signing/notary secrets, preserves all six native archive names, archive documentation, and checksums.txt, and hands the verified binary assets to steipete/homebrew-tap. Signing and notarization happen before independent arm64/Intel verification and publication. Workflow dispatch now owns annotated tag creation.

A GoReleaser post-build check rejects Darwin binaries unless LC_BUILD_VERSION targets macOS 13.0. The same release matrix and regression checks run in macOS CI. Release docs cover the new lifecycle, quarantine/Gatekeeper verification, secret names, and the cgo deployment-flag requirement if cgo is introduced. Remove the unused source-archive Homebrew helper.

Validation: actionlint; GoReleaser config and full snapshot build; deployment-target regression tests; Go build and tests (80.3% coverage); golangci-lint; Docker build/smoke; independent review through P2. Formatting inspection found four pre-existing files outside this change.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge. Reviewed September 14, 2026, 11:20 AM ET / 15:20 UTC.

ClawSweeper review

What this changes

Moves releases to a pinned workflow that signs and notarizes macOS binaries, preserves archive formats, updates Homebrew, and checks the macOS 13 deployment target.

Merge readiness

⛔ Blocked before merge - 3 items remain

The signing work remains useful: current main and v0.2.0 use the unsigned release path. This owner-authored PR should remain open, with one correction to the release guide’s native-execution claim.

Priority: P2
Reviewed head: 5f8e9deb48310a100d06552997903b50c96fbcb6

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused migration with compatible artifact contracts and passing build validation needs one precise release-guide correction.
Proof confidence	🌊 off-meta tidepool	Not applicable: The ordinary contributor-proof gate is exempt for this OWNER-authored PR. The passing macOS snapshot build exercises the deployment-target hook, but does not demonstrate signed, quarantined downloads; the inspected authority checks did not establish a separate unresolved authorization violation.
Patch quality	🐚 platinum hermit (4/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: The ordinary contributor-proof gate is exempt for this OWNER-authored PR. The passing macOS snapshot build exercises the deployment-target hook, but does not demonstrate signed, quarantined downloads; the inspected authority checks did not establish a separate unresolved authorization violation.
Evidence reviewed	8 items	Applicable repository policy: Read the complete root AGENTS.md and searched for nested policies; no additional AGENTS.md or maintainer-notes directory was found. Applied its focused-change and validation guidance without executing builds or tests. Current main still lacks signing: The base release workflow builds on Ubuntu with GoReleaser and contains no Developer ID signing or notarization stage. The current-main release guide explicitly describes ad-hoc signatures. GitHub still identifies v0.2.0 as the latest release; no merged signing replacement appeared in the repository PR listing. Direct dependency contract: The introduced reusable-workflow call executes openclaw/release-workflows at the immutable revision shown here and transfers explicitly named signing, notary, and tap secrets. This establishes the dependency boundary examined in the review.
Findings	1 actionable finding	[P3] Make both native execution checks explicit in the release guide
Security	None	None.

How this fits together

Ordercli’s release pipeline turns a versioned source revision into downloadable binaries and Homebrew updates. The shared workflow builds those binaries, applies Apple signing credentials, verifies the resulting artifacts, and publishes them.

flowchart LR
  A[Version dispatch] --> B[Protected source and metadata checks]
  B --> C[Build six platform binaries]
  C --> D[Check macOS deployment target]
  D --> E[Sign and notarize macOS binaries]
  E --> F[Independent artifact verification]
  F --> G[GitHub release]
  G --> H[Homebrew update]

Loading

Before merge

• Make both native execution checks explicit in the release guide (P3) - The pinned Go CLI workflow verifies signatures, notarization, hashes and architecture, but its verify job never launches the extracted executable. Saying it covers execution on both architectures can lead the release operator to omit the second native smoke check. Replace this claim with an explicit manual quarantined --version check on both arm64 and Intel, distinguishing it from the automated artifact checks.
• Resolve merge risk (P1) - Tag pushes will no longer publish releases; operators must use version dispatch with the required signing secrets and Actions settings. Snapshot CI does not establish that those release prerequisites are configured.
• Complete next step (P2) - Correct the native-execution claim in the release guide and confirm the documented release settings and secret mappings before switching to dispatch.

Findings

• [P3] Make both native execution checks explicit in the release guide — docs/RELEASING.md:39

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Platform compatibility	6 build targets retained; 4 Homebrew targets retained	The migration preserves the existing distribution matrix and native archive naming contract.
Release tooling LOC	Production scripts +88/-20; tests +28/-0	The added scripts implement deployment-target validation, version consistency, and release-note extraction.

Merge-risk options

Maintainer options:

1. Verify the dispatch rollout (recommended)
   Confirm the documented release settings and secret mappings before replacing tag-push publication with version dispatch.

Technical review

Best possible solution:

Preserve the signed-artifact and archive-compatibility design, verify release prerequisites before switching workflows, and explicitly assign quarantined native execution checks on both architectures.

Do we have a high-confidence way to reproduce the issue?

Yes for the review finding: the pinned verifier job can be inspected end-to-end and contains no CLI execution. The original Gatekeeper rejection was not reproduced during this read-only review.

Is this the best way to solve the issue?

Yes, the shared signing workflow is a suitable bounded solution and preserves distribution contracts; the release guide must distinguish artifact verification from native execution.

Full review comments:

• [P3] Make both native execution checks explicit in the release guide — docs/RELEASING.md:39
  The pinned Go CLI workflow verifies signatures, notarization, hashes and architecture, but its verify job never launches the extracted executable. Saying it covers execution on both architectures can lead the release operator to omit the second native smoke check. Replace this claim with an explicit manual quarantined --version check on both arm64 and Intel, distinguishing it from the automated artifact checks.
  Confidence: 0.99

Overall correctness: patch is correct
Overall confidence: 0.9

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 0bb449112ed7.

Labels

Label changes:

• add P2: This is a bounded release improvement addressing macOS download acceptance.
• add merge-risk: 🚨 automation: The PR replaces tag-triggered publication with a dispatch workflow requiring signing credentials and repository setup.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The ordinary contributor-proof gate is exempt for this OWNER-authored PR. The passing macOS snapshot build exercises the deployment-target hook, but does not demonstrate signed, quarantined downloads; the inspected authority checks did not establish a separate unresolved authorization violation.

Label justifications:

• P2: This is a bounded release improvement addressing macOS download acceptance.
• merge-risk: 🚨 automation: The PR replaces tag-triggered publication with a dispatch workflow requiring signing credentials and repository setup.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The ordinary contributor-proof gate is exempt for this OWNER-authored PR. The passing macOS snapshot build exercises the deployment-target hook, but does not demonstrate signed, quarantined downloads; the inspected authority checks did not establish a separate unresolved authorization violation.

Evidence

Acceptance criteria:

• [P1] git diff --check.
• [P1] Compare the revised guide with the verify job in openclaw/release-workflows at f613cbfed2b043159c850c353e7facb8c89833b0.

What I checked:

• Applicable repository policy: Read the complete root AGENTS.md and searched for nested policies; no additional AGENTS.md or maintainer-notes directory was found. Applied its focused-change and validation guidance without executing builds or tests. (AGENTS.md:1, 5f8e9deb4831)
• Current main still lacks signing: The base release workflow builds on Ubuntu with GoReleaser and contains no Developer ID signing or notarization stage. The current-main release guide explicitly describes ad-hoc signatures. GitHub still identifies v0.2.0 as the latest release; no merged signing replacement appeared in the repository PR listing. (.github/workflows/release.yml:20, 0bb449112ed7)
• Direct dependency contract: The introduced reusable-workflow call executes openclaw/release-workflows at the immutable revision shown here and transfers explicitly named signing, notary, and tap secrets. This establishes the dependency boundary examined in the review. (.github/workflows/release.yml:32, 5f8e9deb4831)
• Signing and publication safeguards: Inspected the pinned workflow’s protected-source check, signing identity enforcement, notarization, independent verification, and final publication binding. Publication compares both attestations and downloaded draft bytes, then rechecks the annotated tag target. The dependency tree contains no AGENTS.md. (.github/workflows/release-go-cli.yml:2859, f613cbfed2b0)
• Native verification does not execute the CLI: Read the complete verify job, lines 2432–2804. It checks inventory, hashes, signatures, notarization and architecture, but never executes the extracted CLI or applies quarantine. Consequently it does not support the target release guide’s claim that both architectures receive execution coverage. (.github/workflows/release-go-cli.yml:2726, f613cbfed2b0)
• Homebrew handoff compatibility: The tap workflow accepts the optional assets JSON passed by the shared workflow and supports its expected run title. The existing ordercli formula uses the four Darwin/Linux archive targets retained by this PR. (.github/workflows/update-formula.yml:19, a451014fd308)

Likely related people:

• unknown: The claimed source-line change could not be verified from bounded local history. (role: source history unknown; confidence: low)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Correct the native-execution coverage claim and explicitly require both architecture checks.
• Confirm the documented release prerequisites before switching publication to dispatch.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.