Release binaries are not code-signed, causing blocks in managed/enterprise environments

[built2order]

Summary

The gh-stack release binary is not code-signed (no Apple Developer ID signature on macOS). In enterprise-managed environments that enforce binary allow-listing based on code signatures (eg. macOS 27, Google Santa, Jamf Protect etc.), this causes the extension to be blocked outright for end users, even when the extension itself is legitimate and intentionally installed via gh extension install.

Impact

• Users on managed corporate devices cannot run gh-stack without their security team manually adding a SHA-256 hash exception for every release.
• Unsigned binaries are indistinguishable from untrusted/malicious binaries to allow-listing tools that key off code signing identity — they get the same "blocked" treatment regardless of provenance.
• Hash-based exceptions are brittle: every new release produces a new SHA-256, requiring a fresh manual allow-list entry each time the extension updates. This creates ongoing operational overhead for security teams and friction/delay for users.
• This is a common blocker across the gh extension ecosystem generally, but it specifically impacted us with gh-stack.

Example block event (macOS, Google Santa)

Santa blocked an application
Reason     : Blocked path regex
Path       : <user>/.local/share/gh/extensions/gh-stack/gh-stack
CDHash     : e4a4f41a2f07208222ee829b1cad1977ee07acd5
SHA-256    : 87d3a94333c11f016f9647f61b09c0ce6391de68a6fd9647daf90f970974ba42
Parent     : gh

The binary has no code signature, which rules out signature-based or Team ID-based allow-listing and forces a per-binary, per-release hash exception instead.

Request

Could release binaries be code-signed (and, on macOS, notarized)? Specifically:

• macOS: sign with a Developer ID certificate and notarize releases, similar to how gh itself is distributed.
• Windows: sign with an Authenticode certificate, if not already done.

This would let enterprise security tooling trust the extension by signing identity (eg. Developer ID / Team ID) rather than requiring a new hash exception for every release, which is both safer (verifies authenticity/integrity) and far less operationally costly for teams managing allow lists at scale.