Skip to content

feat(release): notarize PwrAgent macOS binaries - #15

Open
Harold Hunt (huntharo) wants to merge 1 commit into
pwragentfrom
feat/pwragent-macos-notarization
Open

feat(release): notarize PwrAgent macOS binaries#15
Harold Hunt (huntharo) wants to merge 1 commit into
pwragentfrom
feat/pwragent-macos-notarization

Conversation

@huntharo

Copy link
Copy Markdown

Summary

  • notarize all three Developer ID-signed macOS runtime binaries for both arm64 and x86_64 before release packaging
  • submit a temporary ZIP with xcrun notarytool submit --wait and require an Accepted result; continue publishing the existing PwrAgent-compatible .tar.gz assets
  • pin notarization credentials, ordering, exact-byte checks, architecture coverage, and release dependencies in the offline release-policy checker

Motivation

The currently installed managed codex-app-server assesses as Unnotarized Developer ID. PwrAgent launches these provenance-marked binaries frequently, which drives repeated Gatekeeper and syspolicyd work. This change adds notarization to the production managed-runtime path without touching the separate turn_start_zsh_fork test-copy work.

Security and release properties

  1. The protected macos-sign job preserves the existing hardened-runtime, secure-timestamp, Team ID, and Code Mode JIT-entitlement checks.
  2. SHA-256 digests are captured for the exact signed codex, codex-app-server, and codex-code-mode-host bytes before the temporary notarization ZIP is created.
  3. notarytool waits up to 45 minutes and the job fails closed unless the final JSON status is exactly Accepted with a submission ID.
  4. The signed bytes are checked again after acceptance and after extraction from the final tarball. Packaging and upload occur only afterward, so release checksums, update manifests, Sigstore attestations, the publication-complete marker, and release publication remain downstream of successful notarization.
  5. Packaged binaries are independently checked with codesign and assessed by Gatekeeper with spctl, requiring source=Notarized Developer ID with bounded ticket-propagation retries.

Apple supports ZIP as a notarization submission container, but ZIP and tar archives cannot be stapled. A raw standalone Mach-O cannot be stapled either; stapler supports UDIF disk images, code-signed executable bundles, and signed flat installer packages. These unchanged standalone binaries therefore rely on Gatekeeper online ticket retrieval. See Apple custom notarization workflow.

Required GitHub Environment secrets

Configure these additional secrets on the protected apple-signing environment:

  • APPLE_NOTARY_KEY: base64-encoded App Store Connect Team API .p8 private key
  • APPLE_NOTARY_KEY_ID: Team API Key ID
  • APPLE_NOTARY_ISSUER_ID: Team API Issuer ID

The existing CSC_LINK and CSC_KEY_PASSWORD remain required. The runbook now documents environment protection and the fact that the existing 1Password certificate helper does not load notarization credentials.

Verification

  • bash -n scripts/pwragent-release/notarize-macos-binaries.sh
  • shellcheck scripts/pwragent-release/notarize-macos-binaries.sh
  • python3 scripts/pwragent-release/check-release-signing.py
  • python3 scripts/pwragent-release/test_generate_update_manifest.py
  • actionlint .github/workflows/pwragent-release.yml .github/workflows/pwragent-release-check.yml
  • just fmt

The live Apple submission is intentionally not part of ordinary CI. Apply ci:release-signing after the environment secrets are configured to exercise the protected end-to-end path.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant