fix(release): sign all first-party payload binaries

[shanselman]

Fixes #1153.

Summary

• expand the release signing policy from the tray EXE to all eight OpenClaw-owned PE files
• inspect every shipped .exe and .dll
• require a valid signature from the exact published OpenClaw Foundation certificate subject
• fail closed on unknown OpenClaw-named binaries and unknown executables
• preserve explicit third-party/runtime exclusions and reject the OpenClaw signer on those files
• document the binary ownership boundary and update release contract tests

Required website edit before ready

The current OAuth token is not allowed to push .github/workflows/ci.yml. Before marking this PR ready, edit that workflow on this branch in GitHub:

1. Rename the x64/ARM64 staging steps from Executables to Binaries.
2. For each architecture, stage hardlinks for exactly:
   • OpenClaw.Tray.WinUI.exe
   • OpenClaw.Tray.WinUI.dll
   • OpenClaw.Chat.dll
   • OpenClaw.Connection.dll
   • OpenClaw.SetupEngine.UI.dll
   • OpenClaw.SetupEngine.dll
   • OpenClaw.Shared.dll
   • OpenClawTray.FunctionalUI.dll
3. Rename both signing steps to OpenClaw Binaries.
4. Change both Azure Artifact Signing filters from exe to exe,dll.
5. Rename both verification steps from Executable Signing Policy to Binary Signing Policy.

The Azure action's v2 contract explicitly defines files-folder-filter as a comma-separated extension list and gives dll,exe,msix as its example.

Validation

• ./build.ps1: passed Shared, CLI, WinNodeCli, SetupEngine, and WinUI
• Shared tests: 3,757 passed, 32 skipped, 0 failed
• Tray tests: 2,633 passed, 0 skipped, 0 failed
• focused ReleaseSigningWorkflowTests: 4 passed
• real verifier execution under PowerShell 7.6.5:
  • structural policy mode passed a complete synthetic payload
  • release-required mode correctly rejected Microsoft-signed files renamed to OpenClaw binaries because their signer subject was not the exact OpenClaw Foundation subject
• Azure Artifact Signing v2 exe,dll filter syntax verified against the action definition
• final code review: no significant issues
• git diff --check: passed

Real behavior proof

Actual production signing requires the protected release-signing environment and Azure Artifact Signing identity, so it cannot be performed locally. After the workflow edit lands, require a signed release candidate proving all eight first-party PE files have valid OpenClaw Foundation signatures on x64 and ARM64, third-party/runtime files do not carry the OpenClaw signer, and Smart App Control accepts the installed application.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

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

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed August 19, 2026, 9:04 PM ET / August 20, 2026, 01:04 UTC.

ClawSweeper review

What this changes

This PR expands Windows release signing and verification from the tray executable to eight first-party executable and DLL payload binaries.

Regression provenance

Possible regression — probable (reproduction; failure trace). No predecessor PR is attributed.

Merge readiness

⚠️ Ready for maintainer review - 2 items remain

The prior workflow blocker is fixed on the current PR head: both architectures now stage and sign the eight required first-party binaries. Keep this collaborator-owned security repair open for protected release-candidate proof.

Priority: P1
Reviewed head: c04577d0eb8879fb22ced15a20a10d791eef3742

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	The corrected workflow resolves the earlier P1 review finding with focused verifier and contract coverage; protected release-candidate evidence is the remaining confidence reducer.
Proof confidence	🌊 off-meta tidepool	Not applicable: This collaborator-owned release-workflow PR is exempt from the external contributor proof gate; its protected-environment release-candidate proof remains a maintainer merge requirement.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This collaborator-owned release-workflow PR is exempt from the external contributor proof gate; its protected-environment release-candidate proof remains a maintainer merge requirement.
Evidence reviewed	5 items	Prior blocker fixed: The PR head stages the same eight named first-party binaries for x64 and ARM64, signs both staging folders with the exe,dll filter, then runs the verifier on each payload. Verifier covers the new policy: The verifier classifies all executable and DLL files, requires the exact documented OpenClaw signer for the eight owned binaries, rejects OpenClaw signing on third-party files, and rejects unknown OpenClaw-named binaries. Contract test updated: The tray test asserts all eight names, both staging loops, the exe,dll filter, and the exact-signer verifier behavior.
Findings	None	None.
Security	None	None.

Live Verification

Command: pwsh -NoProfile -File .\scripts\Test-ReleaseExecutableSignatures.ps1 -?

Result: FAIL (failed) — execution before step 1 run: sh -lc pnpm install --ignore-scripts --frozen-lockfile failed: ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-11.22.0.tgz

sh -lc pnpm install --ignore-scripts --frozen-lockfile failed: ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-11.22.0.tgz

Assertions:

• FAIL expect_output: OpenClawSignerSubject

How this fits together

The Windows release workflow publishes self-contained tray payloads, stages selected files for Azure Artifact Signing, then verifies payload signatures before creating portable ZIPs and installers. This change protects the boundary between OpenClaw-owned assemblies and bundled third-party/runtime binaries.

flowchart LR
A[Published tray payload] --> B[First-party binary list]
B --> C[Signing staging folders]
C --> D[Azure Artifact Signing]
D --> E[Payload signature verifier]
E --> F[ZIP and installer releases]

Loading

Before merge

• Resolve merge risk (P1) - The tag-only, protected release-signing job has not yet shown that Azure signing preserves valid signatures through hardlink staging for all eight binaries on both architectures.
• Complete next step (P2) - A maintainer must obtain protected release-candidate signing evidence before this draft release workflow can land.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Signing coverage	8 payload binaries across 2 architectures	The workflow and verifier now use the same explicit ownership list for both release payloads.
Production versus test delta	production +122/-51, tests +27/-8	Most change is the release workflow and verifier, with focused contract coverage added for the expanded policy.

Root-cause cluster

Relationship: fixed_by_candidate
Canonical: #1153
Summary: This PR is the concrete candidate fix for the reported unsigned OpenClaw.Chat.dll release payload.

Members:

• canonical: Windows Hub v2026.7.1 is blocked by Smart App Control because OpenClaw.Chat.dll is unsigned #1153 - The PR explicitly targets the reported Smart App Control failure and updates the signing workflow that omitted the DLL.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge-risk options

Maintainer options:

1. Verify a protected release candidate (recommended)
   Run the tag-triggered signing job from this head and retain redacted verifier output for all eight first-party binaries on x64 and ARM64.
2. Pause until signing evidence is available
   Keep the PR draft if the protected release environment cannot yet provide a release-candidate signing run.

Technical review

Best possible solution:

Run a protected signed release candidate from this head and retain its redacted signature-verifier output for x64 and ARM64 before publishing the next release.

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

Yes. Current main source stages only the tray EXE and filters signing to exe, which directly explains why the reported first-party DLL is omitted.

Is this the best way to solve the issue?

Yes. Updating the staging list, Azure filter, verifier, documentation, and contract test together is the narrowest maintainable repair for the release trust boundary.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against a76c85218c7d.

Labels

Label changes:

• add P1: This repair addresses the active Windows Smart App Control block caused by an unsigned first-party payload DLL.
• add merge-risk: 🚨 automation: The changed tag-only signing workflow can fail release automation if Azure signing or hardlink staging does not preserve the expanded binary set.
• 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: This collaborator-owned release-workflow PR is exempt from the external contributor proof gate; its protected-environment release-candidate proof remains a maintainer merge requirement.

Label justifications:

• P1: This repair addresses the active Windows Smart App Control block caused by an unsigned first-party payload DLL.
• merge-risk: 🚨 automation: The changed tag-only signing workflow can fail release automation if Azure signing or hardlink staging does not preserve the expanded binary set.
• 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: This collaborator-owned release-workflow PR is exempt from the external contributor proof gate; its protected-environment release-candidate proof remains a maintainer merge requirement.

Evidence

What I checked:

• Prior blocker fixed: The PR head stages the same eight named first-party binaries for x64 and ARM64, signs both staging folders with the exe,dll filter, then runs the verifier on each payload. (.github/workflows/ci.yml:648, c04577d0eb88)
• Verifier covers the new policy: The verifier classifies all executable and DLL files, requires the exact documented OpenClaw signer for the eight owned binaries, rejects OpenClaw signing on third-party files, and rejects unknown OpenClaw-named binaries. (scripts/Test-ReleaseExecutableSignatures.ps1:44, c04577d0eb88)
• Contract test updated: The tray test asserts all eight names, both staging loops, the exe,dll filter, and the exact-signer verifier behavior. (tests/OpenClaw.Tray.Tests/ReleaseSigningWorkflowTests.cs:6, c04577d0eb88)
• Current-main comparison: Current main still stages only OpenClaw.Tray.WinUI.exe and filters Azure signing to exe, so the PR remains necessary and is not in the current release line. (.github/workflows/ci.yml:648, a76c85218c7d)
• Release-signing provenance: The current workflow/verifier changes date to the PR-head commit by Scott Hanselman; earlier history also records Scott's release-signing policy work and Vincent Koc's Azure Artifact Signing migration. (.github/workflows/ci.yml:648, c04577d0eb88)

Likely related people:

• Scott Hanselman: Authored the current workflow correction and has substantial history on the release signing policy. (role: recent release-signing contributor; confidence: high; commits: c04577d0eb88, 435294415bea; files: .github/workflows/ci.yml, scripts/Test-ReleaseExecutableSignatures.ps1, docs/RELEASING.md)
• Vincent Koc: Repository history attributes the Azure Artifact Signing migration to this contributor. (role: artifact-signing migration contributor; confidence: medium; commits: 9e6f1caa76ad; files: .github/workflows/ci.yml)

Rank-up moves

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

• Run the protected x64 and ARM64 release-candidate signing flow and attach redacted verifier output.

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.

History

Review history (1 earlier review cycle)

• reviewed 2026-08-19T23:13:15.575Z sha 249656b :: found issues before merge. :: [P1] Update the release workflow with the eight-binary staging list