Signing of ToolHive CLI .exe For Windows

WinGet CLI Package Updates Blocked Due to Windows Defender Detections

Summary

WinGet package updates for the ToolHive CLI are consistently getting stuck in the publishing pipeline. Multiple versions (0.3.6, 0.3.7, 0.3.9, 0.3.11) have failed to publish, with the latest available version on WinGet remaining at 0.3.8.

Background

A WinGet moderator confirmed that the delays are primarily caused by Windows Defender false positive detections, which typically clear after a few days. However, this pattern has now affected four consecutive releases, suggesting a systemic issue rather than random occurrences.

Affected Versions

• v0.3.6 - PR #299672 (opened Sep 30) - Eventually merged after moderator intervention
• v0.3.7 - PR #301439 (opened Oct 6) - Eventually merged after moderator intervention
• v0.3.9 - PR #304230 (opened Oct 16) - Currently blocked
• v0.3.11 - PR #304550 (opened Oct 17) - Currently blocked with Internal-Error-Dynamic-Scan, Needs-Attention labels

Pipeline Issues

• PRs are showing Internal-Error-Dynamic-Scan and Retry-1 labels
• Pipeline automation keeps removing and re-adding assignees
• No helpful error messages in pipeline logs
• Same reviewer assigned across multiple stuck PRs

Root Cause Analysis

The Windows CLI executable (thv.exe) is not Authenticode signed, unlike the Windows UI installer which does have proper code signing. Unsigned executables are more likely to trigger Windows Defender false positives during WinGet's automated security scanning.

Proposed Solution

Add Authenticode (DigiCert) signing to the CLI Windows executable in the release build pipeline. Similar to how we do it with the ToolHive Studio

Current State

• Windows UI installer: ✅ Signed with DigiCert
• Windows CLI executable: ❌ Not signed (may have Sigstore signing, but that doesn't help with Windows Defender)
• The signing was likely added after the initial GoReleaser setup, so it was missed for the CLI

Impact

• Windows users cannot install the latest CLI versions via WinGet
• Latest available version stuck at v0.3.8 (3 releases behind)
• Growing backlog of open PRs in microsoft/winget-pkgs
• Users must use alternative installation methods (direct download, Homebrew on WSL)

References

• Internal issue: stacklok/toolhive#2100
• WinGet moderator comment: https://github.com/stacklok/toolhive/issues/2100#issuecomment-...
• WinGet PR queue showing pattern of delays

Start by locating the release build pipeline that produces the Windows CLI executable and compare it with the existing ToolHive Studio signing setup. Verify how thv.exe is packaged and determine where Authenticode signing can be applied; done means the Windows CLI release artifact is signed and suitable for WinGet security scanning.