threat-detection: document macOS support and add installer platform-mapping tests

[davidslater]

Created by GitHub Ace · View Session

Summary

Maintenance follow-up on macOS support for the external detector installer. No functional change is required — actions/setup/sh/install_threat_detect_binary.sh already has a complete install_darwin_binary() branch (lines 153-179) mapping x86_64 → threat-detect-darwin-x64 and arm64 → threat-detect-darwin-arm64, dispatched from the uname -s switch at line 179.

Previously those assets did not exist, so any workflow combining threat-detection.runs-on: macos-* with features: gh-aw-detection: true got a 404 at install time, surfacing as an opaque infra failure rather than a clear "unsupported platform" message. Upstream #741 fixed that: v0.4.0 publishes all four assets. So the latent failure is resolved by the version bump in #50644, and only documentation and test debt remain.

Item 1 — stale header comment

install_threat_detect_binary.sh lines 16-17:

# Platform support:
#   - Linux (x64, arm64): Downloads pre-built binary

The script has supported Darwin for a while and the assets now exist. Update to document macOS x64/arm64.

While editing, note in the header that the macOS assets are unsigned and not notarized. The installer checksum-verifies them before execution (as documented in upstream #741), but users on macOS runners may hit Gatekeeper/quarantine behavior, and that should not be a surprise discovered at runtime.

Item 2 — no installer tests

There is currently no test file for install_threat_detect_binary anywhere in the repo. Add coverage for the OS/arch → asset-name mapping across all four combinations:

uname -s	uname -m	Expected asset
Linux	x86_64	threat-detect-linux-amd64
Linux	aarch64 / arm64	threat-detect-linux-arm64
Darwin	x86_64	threat-detect-darwin-x64
Darwin	arm64	threat-detect-darwin-arm64

Worth also asserting that an unrecognized OS or arch fails fast with an actionable message rather than attempting a 404 download.

Note the asymmetric naming — Linux uses amd64, Darwin uses x64. That inconsistency is exactly the kind of thing a test should pin, since it is easy to "fix" incorrectly during a refactor and the failure only appears at runtime on a macOS runner.

Upstream runs a scheduled parity check validating these mappings against its release-targets.txt, but that protects the publishing side. A test here protects installer behavior locally and catches drift before a release exists.

Acceptance criteria

• Header # Platform support: block documents Linux and macOS (x64, arm64), and notes the macOS assets are unsigned/not notarized with checksum verification as the mitigation.
• Test coverage for all four OS/arch → asset-name mappings.
• Test coverage for the unsupported-platform failure path.

References

• Parity: gh-aw's installer supports threat-detect-darwin-* assets that we never publish gh-aw-threat-detection#702
• feat(release): publish macOS threat detector binaries gh-aw-threat-detection#741
• Upstream draft (for github/gh-aw): compiler-side changes needed for external threat-detect parity gh-aw-threat-detection#726

[pelikhan]

macos is not supported.

[pelikhan]

@copilot the compiler should refuse mac-os execution of the thread-detection.