fix(connection): trust MSIX-packaged wslrelay.exe when Authenticode check fails

[larroy]

Problem

Setup fails on machines running the modern MSIX-distributed WSL (Program Files\WSL, e.g. the Store/GitHub-released package) with:

Loopback port 18789 listener verification failed: wslrelay (PID ...): WSL relay Authenticode verification failed (Unsigned).

MSIX packages don't embed per-file Authenticode/catalog signatures on their EXEs — trust is established at the package level instead (verified by Windows at install time). So wslrelay.exe, wsl.exe, wslhost.exe, etc. from this distribution report Unsigned via WinVerifyTrust/FileSignatureInfo, even though they're genuine, unmodified Microsoft binaries (confirmed via Get-AppxPackage: Publisher = CN=Microsoft Corporation, O=Microsoft Corporation, ...).

Fix

Add a fallback to WindowsAuthenticodeVerifier.VerifyMicrosoftSignedFile: when the primary Authenticode/catalog check fails and the file is wslrelay.exe, corroborate trust via the installed AppX package instead of rejecting outright. The fallback requires all of:

• Exact match on the known WSL package family name MicrosoftCorporationII.WindowsSubsystemForLinux_8wekyb3d8bbwe (the suffix is derived from the publisher's signing certificate, so an impostor package re-signed with a different cert would get a different family name).
• A real SignatureKind (not None) — proves Windows cryptographically validated the package at install time.
• A Microsoft publisher, reusing the existing HasMicrosoftPublisherIdentity check unchanged.

Looked up via a powershell.exe -Command "Get-AppxPackage ... | ConvertTo-Json" shell-out, matching this file's existing pattern for invoking schtasks.exe/wsl.exe elsewhere in ManagedLocalGatewayPortProvenanceService.cs.

The primary Authenticode/catalog check is unchanged, always runs first, and is never bypassed — the fallback only narrows scope to wslrelay.exe and never weakens the trust bar for any other binary. No .csproj/TFM changes; no changes to the canonical-path allowlist.

Testing

• dotnet build src/OpenClaw.Connection/OpenClaw.Connection.csproj — succeeds, 0 warnings/errors.
• dotnet test tests/OpenClaw.Connection.Tests/OpenClaw.Connection.Tests.csproj — 638/638 passing, including 6 new tests covering: trusted-via-fallback, no-package-found, family-name mismatch, unsigned package, non-Microsoft publisher, and a regression test proving the fallback is never consulted when Authenticode already succeeds.

🤖 Generated with Claude Code

[clawsweeper]

🦞👀
ClawSweeper picked this up.

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

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed August 19, 2026, 12:46 PM ET / 16:46 UTC.

ClawSweeper review

What this changes

The PR adds an MSIX package metadata fallback for wslrelay.exe when its ordinary Authenticode verification fails, plus injected-lookup unit tests.

Merge readiness

⛔ Blocked until real behavior proof from a real setup is added - 8 items remain

Keep open. The fallback can trust a relay executable based on metadata from a separately queried WSL package, weakening the local endpoint trust gate that protects shared and bootstrap credentials.

Priority: P0
Reviewed head: aff4e3917f1d7de97e9e68fe2a638bf96d2542ac

Review scores

Measure	Result	What it means
Overall readiness	🧂 unranked krab (1/6)	The compatibility goal is concrete, but the current patch weakens a credential trust boundary and lacks real after-fix evidence.
Proof confidence	🧂 unranked krab (1/6)	Needs real behavior proof before merge: The body reports injected-lookup unit tests, but it has no current-head after-fix evidence from an installed MSIX WSL relay and the actual setup/provenance path. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Patch quality	🦪 silver shellfish (2/6)	Security review found an item that needs attention.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs real behavior proof before merge: The body reports injected-lookup unit tests, but it has no current-head after-fix evidence from an installed MSIX WSL relay and the actual setup/provenance path. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed	5 items	Fallback is not bound to the inspected executable: The changed verifier invokes the MSIX fallback solely because the failed path is named wslrelay.exe; the fallback then validates a separately looked-up package without receiving or comparing the executable path. Existing canonical rule admits any WindowsApps relay filename: The current provenance platform accepts any wslrelay.exe beneath Program Files\WindowsApps before passing it to signature verification; that broad path rule was safe only while per-file verification remained decisive. Provenance gates strong credentials: Managed-local endpoint provenance is explicitly the gate for shared and bootstrap credential use, so misidentifying a relay affects a security boundary rather than only setup diagnostics.
Findings	1 actionable finding	[P1] Bind the fallback to the inspected relay's package
Security	Needs attention	Package metadata does not identify the inspected executable: A genuine WSL package can be present while a different allowed wslrelay.exe owns the listener; the fallback validates only the former and trusts the latter.

Live Verification

Command: dotnet test .\tests\OpenClaw.Connection.Tests\OpenClaw.Connection.Tests.csproj --no-restore --filter "FullyQualifiedName~VerifyMicrosoftSignedFile_AuthenticodeFails"

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: Passed!

How this fits together

Connection setup proves which process owns a local WSL gateway listener before allowing credential fallback. A verified relay and matching WSL service ownership feed the managed-gateway provenance result used by the strong-credential gate.

flowchart LR
A[WSL relay listener] --> B[Canonical path gate]
B --> C[Authenticode verification]
C --> D{Classic trust succeeds?}
D -->|yes| E[Managed gateway provenance]
D -->|no| F[MSIX package fallback]
F --> E
E --> G[Shared or bootstrap credential gate]

Loading

Before merge

• Add real behavior proof - Needs real behavior proof before merge: The body reports injected-lookup unit tests, but it has no current-head after-fix evidence from an installed MSIX WSL relay and the actual setup/provenance path. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• Bind the fallback to the inspected relay's package (P1) - The current path gate accepts any wslrelay.exe below Program Files\WindowsApps, but this fallback only proves that a WSL package exists. An unrelated package's relay can therefore inherit that package's trust and pass the provenance gate that permits shared/bootstrap credentials. Return package ownership data such as its install location and reject paths outside that exact package, with a sibling-WindowsApps regression test.
• Resolve security concern: Package metadata does not identify the inspected executable - A genuine WSL package can be present while a different allowed wslrelay.exe owns the listener; the fallback validates only the former and trusts the latter.
• Resolve merge risk (P1) - An unrelated wslrelay.exe under the existing WindowsApps allowlist can inherit trust from an installed WSL package, potentially passing the provenance gate that permits shared or bootstrap credentials.
• Resolve merge risk (P1) - The PR provides mock-oriented unit tests but no redacted after-fix proof from an installed MSIX WSL relay and real setup path.
• Complete next step (P2) - A narrow source-proven security-boundary repair is available, but real MSIX setup proof remains a contributor merge requirement.
• Improve patch quality - Bind the fallback to the inspected executable's registered WSL package and add the regression test.
• Improve patch quality - Post redacted current-head Windows proof showing the real MSIX relay passes setup; omit tokens, private endpoints, and identifiers.

Findings

• [P1] Bind the fallback to the inspected relay's package — src/OpenClaw.Connection/WindowsAuthenticodeVerifier.cs:59
• [high] Package metadata does not identify the inspected executable — src/OpenClaw.Connection/WindowsAuthenticodeVerifier.cs:115

Agent review details

Security

Needs attention: The fallback disconnects executable identity from package identity in a credential-protecting trust decision.

Review metrics

Metric	Value	Why it matters
Trust-logic delta	production +196, tests +88	A narrow compatibility fallback adds a new PowerShell and JSON trust path, so its executable-to-package binding needs focused review.

Merge-risk options

Maintainer options:

1. Bind package trust to the relay path (recommended)
   Return the registered WSL package installation path or equivalent authoritative ownership data and accept the fallback only when the inspected relay belongs to that package, then add a sibling-WindowsApps rejection test and real MSIX proof.
2. Preserve the existing fail-closed verifier
   If package ownership cannot be proven from a supported Windows trust API, do not merge the fallback because the current per-file verification is the safer credential-gate behavior.

Technical review

Best possible solution:

Bind any package-level fallback to the registered Microsoft WSL package that owns the inspected executable, fail closed for every other path, and publish redacted real Windows MSIX proof after the repair.

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

Yes: source shows that any failed path named wslrelay.exe can receive Trusted from valid WSL package metadata without a path-to-package comparison; a focused regression can model an unrelated WindowsApps sibling relay.

Is this the best way to solve the issue?

No: the fallback must prove that the inspected executable belongs to the trusted WSL package, rather than treating the presence of that package as corroboration for another executable.

Full review comments:

• [P1] Bind the fallback to the inspected relay's package — src/OpenClaw.Connection/WindowsAuthenticodeVerifier.cs:59
  The current path gate accepts any wslrelay.exe below Program Files\WindowsApps, but this fallback only proves that a WSL package exists. An unrelated package's relay can therefore inherit that package's trust and pass the provenance gate that permits shared/bootstrap credentials. Return package ownership data such as its install location and reject paths outside that exact package, with a sibling-WindowsApps regression test.
  Confidence: 0.96

Overall correctness: patch is incorrect
Overall confidence: 0.96

AGENTS.md: found and applied where relevant.

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

Labels

Label changes:

• add P0: The changed trust decision can allow a misidentified local listener through a credential-protecting security gate.
• add merge-risk: 🚨 security-boundary: Merging the fallback can weaken the provenance check that guards shared and bootstrap credential use.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦪 silver shellfish.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The body reports injected-lookup unit tests, but it has no current-head after-fix evidence from an installed MSIX WSL relay and the actual setup/provenance path. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Label justifications:

• P0: The changed trust decision can allow a misidentified local listener through a credential-protecting security gate.
• merge-risk: 🚨 security-boundary: Merging the fallback can weaken the provenance check that guards shared and bootstrap credential use.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦪 silver shellfish.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The body reports injected-lookup unit tests, but it has no current-head after-fix evidence from an installed MSIX WSL relay and the actual setup/provenance path. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence

Security concerns:

• [high] Package metadata does not identify the inspected executable — src/OpenClaw.Connection/WindowsAuthenticodeVerifier.cs:115
  A genuine WSL package can be present while a different allowed wslrelay.exe owns the listener; the fallback validates only the former and trusts the latter.
  Confidence: 0.96

Acceptance criteria:

• [P1] ./build.ps1.
• [P1] dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore.
• [P1] dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore.
• [P1] dotnet test ./tests/OpenClaw.Connection.Tests/OpenClaw.Connection.Tests.csproj --no-restore.
• [P1] Redacted real Windows MSIX WSL setup/provenance proof from the repaired PR head.

What I checked:

• Fallback is not bound to the inspected executable: The changed verifier invokes the MSIX fallback solely because the failed path is named wslrelay.exe; the fallback then validates a separately looked-up package without receiving or comparing the executable path. (src/OpenClaw.Connection/WindowsAuthenticodeVerifier.cs:59, aff4e3917f1d)
• Existing canonical rule admits any WindowsApps relay filename: The current provenance platform accepts any wslrelay.exe beneath Program Files\WindowsApps before passing it to signature verification; that broad path rule was safe only while per-file verification remained decisive. (src/OpenClaw.Connection/ManagedLocalGatewayPortProvenanceService.cs:72, 4206611f2b2e)
• Provenance gates strong credentials: Managed-local endpoint provenance is explicitly the gate for shared and bootstrap credential use, so misidentifying a relay affects a security boundary rather than only setup diagnostics. (src/OpenClaw.Connection/ManagedLocalGatewayPortProvenanceService.cs:293, b37307cbd51f)
• Current main and release check: Current main retains the original per-file verifier and does not contain this fallback. The latest local release tag v2026.7.1 points to the earlier trust-gate commit, while this candidate remains an unmerged PR head. (src/OpenClaw.Connection/WindowsAuthenticodeVerifier.cs:16, b37307cbd51f)
• Feature provenance: The existing relay provenance and Authenticode trust gate were introduced together by the same source commit. (src/OpenClaw.Connection/WindowsAuthenticodeVerifier.cs:16, 4206611f2b2e)

Likely related people:

• Scott Hanselman: Commit 4206611 introduced both the canonical relay-path check and the original per-file Authenticode verifier. (role: introduced the relay provenance trust gate; confidence: high; commits: 4206611f2b2e; files: src/OpenClaw.Connection/ManagedLocalGatewayPortProvenanceService.cs, src/OpenClaw.Connection/WindowsAuthenticodeVerifier.cs)

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.