Code-sign CLI Windows binaries before release

[ChiragAgg5k]

Summary

• Add Windows code-signing to the CLI publish workflow before GitHub release asset upload.
• Upload unsigned Windows CLI binaries as a GitHub Actions artifact, submit them to the configured signing provider, and replace the release assets with the signed outputs.
• Pin the current signing provider action to an immutable commit SHA and verify the returned Windows binaries with osslsigncode before publishing.

Configuration required

• WINDOWS_SIGNING_API_TOKEN repository secret
• WINDOWS_SIGNING_ORGANIZATION_ID repository variable
• WINDOWS_SIGNING_POLICY_SLUG repository variable, e.g. test-signing
• Optional repository variables: WINDOWS_SIGNING_PROJECT_SLUG, WINDOWS_SIGNING_ARTIFACT_CONFIGURATION_SLUG

Tests

• docker run --rm -v $(pwd):/app -w /app php:8.3-cli php example.php cli
• composer lint-twig
• `ruby -e 'require "yaml"; YAML.load_file("templates/cli/.github/workflows/publish.yml"); puts "YAML ok"'

[greptile-apps]

Greptile Summary

This PR inserts a Windows binary code-signing stage into the CLI publish workflow using SignPath. Unsigned executables are uploaded as a GitHub Actions artifact, submitted to SignPath for signing, replaced in the build/ directory, and verified with osslsigncode before the existing release-upload step runs.

• The SignPath action is correctly pinned to an immutable commit SHA (b9d91eadd...) rather than the mutable v2 tag.
• The actions: read permission is added, which is required for the SignPath action to download the artifact from the Actions API.
• The windows-unsigned artifact has no retention-days setting, leaving unsigned binaries publicly accessible for the full repository retention period (typically 90 days) even though SignPath downloads them within the same workflow run; setting retention-days: 1 would limit this exposure.

Confidence Score: 5/5

Safe to merge; the signing integration is structurally correct and the SignPath action is pinned to an immutable SHA.

The new signing steps are well-structured: the SignPath action is pinned to a commit SHA, the binary-replacement logic uses set -euo pipefail and explicit existence checks, and the workflow correctly fails closed if signing is rejected. The two findings are a missing retention-days on the unsigned artifact and a documentation naming discrepancy between the PR description and the actual secret names, neither of which affects whether signing or publishing works correctly when the repository is properly configured.

No files require special attention; the single changed workflow file is straightforward.

Important Files Changed

Filename	Overview
templates/cli/.github/workflows/publish.yml	Adds a SignPath code-signing stage for Windows binaries before release upload; SignPath action is correctly pinned to a commit SHA, but the unsigned artifact has no retention limit and the configured secret/variable names don't match the PR description.

_{Reviews (5): Last reviewed commit: "Code-sign CLI Windows binaries before re..." | Re-trigger Greptile}

[ChiragAgg5k]

Addressed Greptile's security comments in 2c9e27f:\n\n- pinned signpath/github-action-submit-signing-request to commit b9d91eadd323de506c0c81cf0c7fe7438f3360fd instead of the mutable v2 tag\n- tightened signature verification by requiring SIGNPATH_TRUSTED_CERTIFICATE_PEM for osslsigncode -CAfile and SIGNPATH_EXPECTED_SIGNER_SUBJECT for signer identity matching