fix(ci): migrate release signing to Azure Artifact Signing

[vincentkoc]

Summary

• move release signing to Azure Artifact Signing on the openclaw account/profile in East US
• switch GitHub Actions Azure auth from client-secret JSON to OIDC in the release-signing environment
• sign both x64 and ARM64 payload executables in the release job before zipping/installers
• update the release docs, MSIX publisher subject, signer verifier, and workflow tests for the OpenClaw Foundation cert

Validation

• ruby -e 'require "yaml"; YAML.load_file(".github/workflows/ci.yml")'
• git diff --check
• Azure CLI verified openclaw signing account/profile are active and the GitHub OIDC app has Artifact Signing Certificate Profile Signer on the profile scope
• GitHub signing smoke with direct OIDC IDs passed: https://github.com/openclaw/openclaw-windows-node/actions/runs/26642787219
• GitHub signing smoke with refreshed repo secrets passed: https://github.com/openclaw/openclaw-windows-node/actions/runs/26642979324

Local required gates blocked on this mac:

• ./build.ps1 -> permission denied for direct ps1 execution in zsh
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore -> dotnet not installed
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore -> dotnet not installed

[clawsweeper]

Codex review: found issues before merge. Reviewed May 29, 2026, 10:35 AM ET / 14:35 UTC.

Summary
This PR replaces the tag-release signing flow with Azure Artifact Signing/OIDC, updates OpenClaw Foundation signer metadata, and refreshes release-signing docs/tests.

Reproducibility: not applicable. this is a release-signing workflow migration rather than a bug report. The relevant runtime evidence is the linked signing smoke runs and current-head CI status.

Review metrics: 3 noteworthy metrics.

• Changed surface: 5 files, +90/-88. The diff spans workflow, docs, manifest identity, verifier defaults, and tests, so release review must cover more than YAML syntax.
• Shipped MSIX assets: 2 .msix assets in v0.5.0. The manifest publisher change affects a package identity that has already shipped.
• Signing action usage: 3 artifact-signing-action steps. Payload and installer signing all move to the new action, so release automation depends on the same new OIDC signing path.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦞 diamond lobster ✨ media proof bonus
Patch quality: 🦐 gold shrimp
Result: needs maintainer review before merge.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Resolve or explicitly approve the MSIX publisher identity transition.
• [P2] Let current-head Build and Test finish successfully before merge.
• Have release owners confirm the release-signing environment and OIDC role assignment.

Risk before merge

• [P1] Changing the MSIX Identity Publisher changes the package identity; v0.5.0 shipped MSIX assets under the old publisher, so future MSIX releases need an explicit upgrade/reinstall plan or release-owner acceptance.
• [P1] The tag-release path now depends on the release-signing environment and Azure OIDC setup; the PR links successful signing smokes, but the full production tag flow still needs release-infra sign-off.
• [P1] At review time, current-head Build and Test was still in progress, while the local AGENTS-required build/test commands were reported blocked by the contributor's macOS environment.

Maintainer options:

1. Resolve the MSIX identity break (recommended)
   Preserve the old MSIX publisher until a migration/reinstall plan is documented, or get explicit release-owner approval that future MSIX users must move to the new identity.
2. Accept a deliberate MSIX reset
   Maintainers can intentionally accept that the foundation certificate creates a new MSIX package identity, but that should be recorded before merge.
3. Split signing from MSIX identity
   If the OIDC signing migration is urgent, remove the manifest publisher change from this PR and track the MSIX identity transition separately.

Next step before merge

• [P2] This draft member-authored release-signing PR needs maintainer release-compatibility and environment approval rather than an automated repair lane.

Security
Cleared: No concrete security or supply-chain regression found beyond the compatibility/automation risks already called out; the diff removes client-secret JSON and keeps allowlisted signing plus verification.

Review findings

• [P1] Account for the MSIX publisher identity break — src/OpenClaw.Tray.WinUI/Package.appxmanifest:17

Review details

Best possible solution:

Land the migration after preserving or explicitly documenting the MSIX publisher upgrade path, confirming the release-signing OIDC environment, and letting current-head CI finish cleanly.

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

Not applicable; this is a release-signing workflow migration rather than a bug report. The relevant runtime evidence is the linked signing smoke runs and current-head CI status.

Is this the best way to solve the issue?

No as-is; the OIDC/Artifact Signing direction is reasonable, but the MSIX publisher identity change needs explicit compatibility handling because v0.5.0 shipped MSIX assets under the old publisher.

Full review comments:

• [P1] Account for the MSIX publisher identity break — src/OpenClaw.Tray.WinUI/Package.appxmanifest:17
  Changing Identity Publisher changes the MSIX package identity. The latest release still shipped x64 and ARM64 .msix assets under the current publisher, so a future unpaused MSIX release from this manifest will not be an in-place update for those users unless the PR preserves the identity, documents a reinstall/migration path, or records explicit release-owner acceptance of that break.
  Confidence: 0.88

Overall correctness: patch is incorrect
Overall confidence: 0.86

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 32e6025d00c6.

Label changes

Label changes:

• add P2: This is a normal-priority release-infrastructure change with limited direct user blast radius until the next release, but it needs careful compatibility review.
• add merge-risk: 🚨 compatibility: The PR changes the MSIX publisher identity even though MSIX artifacts shipped in v0.5.0 under the old publisher.
• add merge-risk: 🚨 automation: The PR rewires tag-release signing and Azure authentication, which ordinary PR checks do not fully exercise as a production tag release.
• add proof: sufficient: Contributor real behavior proof is sufficient. The PR links successful Signing Smoke runs that built, Azure-logged-in, signed, and verified a smoke executable on the branch.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (linked_artifact): The PR links successful Signing Smoke runs that built, Azure-logged-in, signed, and verified a smoke executable on the branch.

Label justifications:

• P2: This is a normal-priority release-infrastructure change with limited direct user blast radius until the next release, but it needs careful compatibility review.
• merge-risk: 🚨 compatibility: The PR changes the MSIX publisher identity even though MSIX artifacts shipped in v0.5.0 under the old publisher.
• merge-risk: 🚨 automation: The PR rewires tag-release signing and Azure authentication, which ordinary PR checks do not fully exercise as a production tag release.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (linked_artifact): The PR links successful Signing Smoke runs that built, Azure-logged-in, signed, and verified a smoke executable on the branch.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR links successful Signing Smoke runs that built, Azure-logged-in, signed, and verified a smoke executable on the branch.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its validation guidance matters because the PR body reports local required gates blocked and current-head CI was still running during review. (AGENTS.md:1, 32e6025d00c6)
• Release workflow migration: The PR head adds the release-signing environment, grants id-token: write, and switches signing steps to azure/artifact-signing-action@v2 with the openclaw account/profile. (.github/workflows/ci.yml:516, a6e298ad838c)
• MSIX publisher changed: The PR head changes the MSIX Identity Publisher to the OpenClaw Foundation certificate subject. (src/OpenClaw.Tray.WinUI/Package.appxmanifest:17, a6e298ad838c)
• Current shipped identity: Current main still uses the Scott Hanselman publisher subject, which forms part of the MSIX package identity. (src/OpenClaw.Tray.WinUI/Package.appxmanifest:17, 32e6025d00c6)
• Latest release includes MSIX: The latest v0.5.0 release published both x64 and ARM64 MSIX assets, so the publisher identity change can affect existing MSIX installations when MSIX packaging resumes.
• Signing smoke proof: The linked Signing Smoke run completed successfully and its job built, Azure-logged-in, signed, and verified a smoke executable on the branch. (396ec5afe6df)

Likely related people:

• shanselman: Blame and file history show Scott Hanselman introduced and recently updated most of the release job, signing allowlist, release docs, and signing workflow tests. (role: release-signing feature owner; confidence: high; commits: 8714381248a2, 528f625edc5b, 435294415bea; files: .github/workflows/ci.yml, docs/RELEASING.md, scripts/Test-ReleaseExecutableSignatures.ps1)
• vincentkoc: Current-main history includes a recent CI workflow permission/security commit by Vincent Koc, making him relevant to adjacent workflow review beyond opening this PR. (role: recent CI contributor; confidence: medium; commits: b906e1ba8f00; files: .github/workflows/ci.yml)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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.

How this review workflow works

• 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.