Request for official Authenticode signing identity for GitHub CLI v2.103.3 (Windows AMD64)

[crcell]

Title: Request for official Authenticode signing identity for GitHub CLI v2.103.3 (Windows AMD64)

Hello GitHub CLI maintainers,

We are designing a security-sensitive, auditable software deployment and backup workflow that uses GitHub CLI to verify artifact attestations.

Before executing the GitHub CLI binary on Windows, we need to establish an independently verifiable trust policy for the official release artifact.

Target release:

• Repository: https://github.com/cli/cli
• Version: v2.103.3
• Archive: gh_2.103.3_windows_amd64.zip
• Expected executable: bin/gh.exe
• Published archive SHA256: 98d0cfa794721665d7973dd728c78aff7bd836d58f10f6d7a03568eccb0a22e0
• Published artifact attestation: https://github.com/cli/cli/attestations/60065904

We have reviewed the release workflow and signing script, which reference Azure Code Signing and the GitHubInc signing profile. However, we have not established an authoritative binding between that profile and the expected Authenticode certificate identity for this specific executable.

Could you please clarify:

1. Expected signing identity: What X.509 Subject, organization, and certificate identity should be expected for the Authenticode signature on bin/gh.exe in this release?

2. Authoritative reference: Is there an official, publicly accessible statement or signed metadata that independently binds this identity to the GitHub CLI Windows release?

3. Certificate rotation: What stable publisher or signing-profile identifier should security-sensitive consumers validate across legitimate certificate renewals, rather than pinning a single certificate thumbprint indefinitely?

4. Verification procedure: Is there a recommended Windows-native verification procedure that validates the embedded Authenticode signature, publisher identity, certificate chain, timestamp, and revocation status before executing the binary?

5. Independent bootstrap: Is there an officially supported method to verify the release artifact's provenance without first executing an unauthenticated copy of GitHub CLI?

We are not requesting private certificates, signing credentials, or other sensitive information. Public certificate identity information and official verification documentation would be sufficient.

Our goal is to establish a reproducible, fail-closed verification process suitable for deployment across independently managed Windows environments.

Thank you for your guidance.

[Icaro0310]

Pin the cert subject, not the thumbprint. Thumbprints change every renewal, so a policy keyed on them breaks silently. Check what your binary actually has:

Get-AuthenticodeSignature .\gh.exe | Select-Object -ExpandProperty SignerCertificate | fl Subject, Issuer, Thumbprint

Recent Windows releases are signed by a DigiCert cert issued to "GitHub, Inc.". I'd pin the publisher (CN=GitHub, Inc.) plus the issuing CA in your AppLocker/WDAC policy, that survives renewals.

Since you're already in the attestation workflow: gh publishes provenance for its own binaries, so gh attestation verify gh.exe --repo cli/cli gives you the supply-chain check on top of Authenticode.

—
More of my work lives here: github.com/Icaro0310 · Website: icaro0310.github.io

[stanczykwyatt]

I checked the exact release ZIP you named, without executing its gh.exe. Its SHA-256 matches 98d0cfa794721665d7973dd728c78aff7bd836d58f10f6d7a03568eccb0a22e0. On the extracted bin/gh.exe, Windows reports a valid Authenticode signature with:

Subject: CN="GitHub, Inc.", O="GitHub, Inc.", L=San Francisco, S=California, C=US
Issuer:  CN=Microsoft ID Verified CS EOC CA 04, O=Microsoft Corporation, C=US
Timestamp signer: Microsoft Public RSA Time Stamping Authority

So the DigiCert issuer assumption in the earlier reply doesn't match this particular artifact. I wouldn't build the requested rotation policy around that assumption.

You can inspect the same fields without launching the downloaded executable:

$signature = Get-AuthenticodeSignature -LiteralPath .\bin\gh.exe
$signature.Status
$signature.SignerCertificate | Format-List Subject, Issuer, Thumbprint
$signature.TimeStamperCertificate | Format-List Subject, Issuer

For Windows SDK verification, Microsoft's documented options give:

signtool verify /pa /all /v /tw .\bin\gh.exe

/pa selects Authenticode policy, /all checks all signatures, and /tw warns if a timestamp is absent. A fail-closed caller should handle warnings as well as failures. See the SignTool reference.

This establishes what is in the artifact and its verification result on this Windows machine. It does not supply the independent publisher/profile binding or future certificate-rotation commitment you're asking the maintainers to publish. Those parts of your question still need an authoritative project statement; deriving the expected identity solely from the downloaded file would be circular.