[ci] Sign and notarize macOS releases with rcodesign directly

Sign and notarize by calling rcodesign directly instead of the
indygreg/apple-code-sign-action:

- The sign-publish job already installs rcodesign and calls it for
  encode-app-store-connect-api-key; the action only wrapped the sign and
  notarize steps, so this consolidates on one way of invoking the tool.
- Drops a third-party action (personal namespace) that handled the PKCS#12
  password and notarization API key. This repo SHA-pins third-party actions
  from non-vendor namespaces; indygreg/ was the only non-vendor action on a
  floating tag (GitHub actions/* and AWS aws-actions/* stay on version tags).

Harden the release job:
- Pin the rcodesign tarball to a repo-held SHA256 (APPLE_CODESIGN_SHA256 in
  the workflow, per-arch digests in the builder-image script) rather than
  trusting the release's own .sha256 sidecar, which a compromised release
  could replace alongside the tarball.
- Restrict the push trigger to release tags (tags: ["v*"]) so a non-release
  tag push cannot sign and publish artifacts, matching build-linux-packages.yml.
- Delete each signing secret immediately after its last use (P8 after encoding
  the API key, P12 after Apple-signing, GPG key after zip-signing, API JSON
  after notarization), so none remain on disk once the AWS credentials action
  and upload-artifact run. An ERR trap in the credential-materialization step
  removes the temp files if it fails before their paths are cleanup-tracked;
  the always() Cleanup remains the backstop for later steps.
- Upload each zip's detached .sig to S3 before the zip itself, so a partial
  upload cannot leave a consumable zip without its signature.
- Check out the requested tag on workflow_dispatch (ref:) and refuse to
  build/sign a non-tag ref, mirroring build-linux-packages.yml.

Also:
- Note in the workflow env block that the packaging Taskfile greps
  APPLE_CODESIGN_PKG_VERSION from this file.
- Comment why executable bits are restored after artifact download, and that
  setup_gpg materializes the key at NFPM_SIGNING_KEY.
- macos-zip.md: reword "load-bearing"/"Tier 1/2/3" jargon, fix a 404 notary
  link, note DEB now shares the GPG key, and rewrite the action-pinning
  section to reflect the direct-rcodesign approach.

Author: PlatCore

.github/packaging/macos-zip.md

@@ -32,8 +32,8 @@ Per architecture, the macOS packaging pipeline produces:
 Each Mach-O binary inside a zip carries an Apple code signature with the
 `runtime` hardened-runtime flag. Each zip is signed with the project's GPG
 key and submitted to Apple's notary service before being published. The
-order is load-bearing; see *Apple-sign / GPG-sign / notarize order* in the
-maintenance notes.
+order of those three operations matters; see *Apple-sign / GPG-sign /
+notarize order* in the maintenance notes.
 
 ### Main entrypoints
 
@@ -118,20 +118,31 @@ runner.
 
 Apple signing, notarization, and publishing all run on Linux because:
 
-- `indygreg/apple-code-sign-action@v1` is a Node JS action and runs on any
-  runner that supports Node 20+
-- the underlying `rcodesign` tool is cross-platform and ships pre-built Linux
-  binaries for both `x86_64` and `aarch64`
-- macOS GitHub-hosted minutes are roughly 10× the price of Linux minutes; the
+- `rcodesign` is cross-platform and ships pre-built Linux binaries for both
+  `x86_64` and `aarch64`, so Apple-signing and notary submission never need a
+  macOS host
+- macOS GitHub-hosted minutes are roughly 10x the price of Linux minutes; the
   parts of the pipeline that do not require a Mach-O build environment should
   not pay that premium
 
 ### Credential lifecycle
 
-All Apple credentials and the GPG key are materialized into `mktemp` files
-and are explicitly removed by the workflow's `Cleanup` step (which runs
-`if: always()`). They are not echoed via `GITHUB_OUTPUT` and never reach
-either the GitHub Releases page or the `s3://${BUCKET}/macos/` prefix.
+All Apple credentials and the GPG key are materialized into `mktemp` files and
+each is deleted as soon as its last consumer finishes, so a given secret is on
+disk only across the steps that actually use it:
+
+| Secret | Materialized in | Deleted after |
+| --- | --- | --- |
+| App Store Connect P8 | `Materialize Apple credentials` | encoding the API-key JSON (same step; its path is never exported) |
+| Signing PKCS#12 | `Materialize Apple credentials` | `Apple-sign binaries` |
+| GPG private key | `Import GPG key` | `Build zips and GPG-sign` |
+| Encoded API-key JSON | `Materialize Apple credentials` | `Notarize zips` |
+
+By the time the AWS credentials action and `upload-artifact` run, no signing
+secret remains on disk. The `Cleanup` step (`if: always()`) is the backstop for
+failure paths that abort before a per-step delete. The credentials are not
+echoed via `GITHUB_OUTPUT` and never reach either the GitHub Releases page or
+the `s3://${BUCKET}/macos/` prefix.
 
 The local validator mirrors this: ephemeral Apple PKCS#12, GPG private key,
 and ECDSA P8 are all written into a `mktemp -d` stage directory cleaned up by
@@ -165,8 +176,8 @@ produces an artifact whose internal entries are `avalanchego` and `subnet-evm`
 ```
 
 Downstream steps reference `build/avalanchego` and `build/subnet-evm`
-explicitly, so the `path: build` is load-bearing - using `path: .` would
-land the files at the workspace root and break the rest of the workflow.
+explicitly, so the `path: build` matters here - using `path: .` would land
+the files at the workspace root and break the rest of the workflow.
 
 The production `build-zip-pkg.sh` then calls `7z a foo.zip build/avalanchego`,
 which preserves the `build/` prefix inside the zip. The validator therefore
@@ -179,10 +190,11 @@ The local validator (`build-macos-zip.sh`) invokes the production
 therefore exercises the same zip + GPG-sign code that runs in CI, not a copy.
 Behavioral divergence between local and CI is structurally avoided.
 
-The Apple-sign and notarize steps are not yet wrapped this way because they
-live inside the `indygreg/apple-code-sign-action@v1` Node JS action rather
-than in a separate script; the local validator invokes `rcodesign` directly
-with the same flag shapes the action uses.
+The Apple-sign, notarize, and API-key-encode steps call `rcodesign` directly
+in both places (CI's `sign-publish` job and the local validator), with the
+same flags. CI installs `rcodesign` from the `indygreg/apple-platform-rs`
+release; the validator bakes it into its Docker image. Neither path depends
+on a third-party GitHub Action to reach the signing tool.
 
 ## Maintenance notes
 
@@ -192,41 +204,50 @@ Apple's `codesign` only runs on macOS. The sign-publish job runs on Linux for
 cost reasons (see *Two-job split* above), so the signing tool must work on
 Linux. `rcodesign` (from `indygreg/apple-platform-rs`) is a pure-Rust
 re-implementation of Apple code-signing and notary submission that works
-without macOS. It is the same tool wrapped by
-`indygreg/apple-code-sign-action`, so using `rcodesign` directly in the local
-validator and via the action in CI keeps the underlying signing
-implementation consistent across both paths.
-
-### Why `indygreg/apple-code-sign-action@v1` is currently pinned by major tag
-
-The action is currently pinned to the floating `v1` tag rather than a full
-commit SHA. The pragmatic trade-off:
-
-- `v1` follows the same pinning pattern as other GitHub Actions in this
-  repository's release workflows (`actions/checkout@v5`,
-  `aws-actions/configure-aws-credentials@v6`, etc.). Internal consistency.
-- A retag of `v1` to a malicious commit would let an attacker exfiltrate the
-  PKCS#12 password and notarization API key. The action is on a personal
-  GitHub namespace (`indygreg/`), which is meaningfully higher supply-chain
-  risk than first-party `actions/*` and `aws-actions/*` pins.
-
-The tarball that `indygreg/apple-platform-rs` ships is already SHA256-pinned
-in the local validator's Dockerfile (`Dockerfile.macos-zip`), via the
-`*.sha256` sidecar from the release. The CI workflow itself does not yet
-SHA-pin either the action or the rcodesign tarball it downloads inline.
-
-When the upstream API stabilizes or supply-chain risk increases enough to
-justify the maintenance overhead, pin to a full commit SHA and enable
-Dependabot to update it.
+without macOS. Both the CI `sign-publish` job and the local validator invoke
+`rcodesign` directly, so the underlying signing implementation is identical
+across both paths.
+
+### Why the signing tool is `rcodesign` invoked directly, not a GitHub Action
+
+Earlier revisions of this workflow wrapped signing and notarization in the
+`indygreg/apple-code-sign-action` GitHub Action, a thin Node wrapper that
+downloads `rcodesign` and shells out to it. It was dropped in favor of
+calling `rcodesign` directly because:
+
+- The `sign-publish` job already installs `rcodesign` (it needs it for
+  `encode-app-store-connect-api-key`) and the local validator already calls
+  it directly. Using the action for only the sign/notarize steps meant two
+  different ways of invoking the same tool inside one job.
+- The action lives in a personal GitHub namespace (`indygreg/`) and handled
+  the PKCS#12 password and notarization API key. A retag of its floating `v1`
+  to a malicious commit would have let it exfiltrate those secrets. This
+  repository SHA-pins third-party actions from non-vendor namespaces for
+  exactly this reason (GitHub's own `actions/*` and AWS's `aws-actions/*` stay
+  on version tags); `indygreg/` was the only non-vendor action on a floating
+  tag.
+
+The remaining actions in the sign-publish job are the vendor ones
+(`actions/checkout`, `actions/*-artifact`, `aws-actions/configure-aws-credentials`).
+The two that run after credentials are materialized (`configure-aws-credentials`
+and `upload-artifact`) run only after every signing secret has already been
+deleted at its last point of use (see *Credential lifecycle*).
+
+Supply-chain integrity of the tool itself is handled by pinning the
+`rcodesign` release tarball's SHA256 in this repository, rather than trusting
+the release's own `*.sha256` sidecar (a compromised release could replace the
+tarball and the sidecar together). The CI workflow verifies against
+`APPLE_CODESIGN_SHA256`; the local builder image passes the per-arch digest as
+a Docker build arg (both live next to the pinned version and must be updated
+together on a version bump).
 
 ### Apple-sign / GPG-sign / notarize order
 
 The CI workflow performs the signing operations in this order, and the
-order is load-bearing:
+order matters:
 
-1. **Apple-sign each Mach-O binary** (`rcodesign sign` via the action). The
-   signature is embedded inside the Mach-O via the `LC_CODE_SIGNATURE` load
-   command.
+1. **Apple-sign each Mach-O binary** (`rcodesign sign`). The signature is
+   embedded inside the Mach-O via the `LC_CODE_SIGNATURE` load command.
 2. **Zip each binary and detached-GPG-sign the resulting zip**
    (`build-zip-pkg.sh`). The GPG signature is over the zip bytes, which
    include the already-Apple-signed Mach-O.
@@ -261,20 +282,21 @@ This is a deliberate guard against a previously-latent failure mode:
 The precondition replaces "publish unsigned then error" with "fail at the
 import step with a clear message."
 
-### Why `secrets.RPM_GPG_PRIVATE_KEY` is shared with RPM signing
+### Why `secrets.RPM_GPG_PRIVATE_KEY` is shared across package formats
 
-The macOS zip workflow reuses the same GPG private key as the RPM packaging
-workflow rather than introducing a `MACOS_GPG_PRIVATE_KEY` secret.
+The macOS zip workflow reuses the same GPG private key as the RPM and DEB
+packaging workflows rather than introducing a `MACOS_GPG_PRIVATE_KEY` secret.
 
 Rationale: the GPG key identifies *the project*, not the package format. End
 users who want to verify "is this artifact really from ava-labs?" use the
-same key whether they downloaded an RPM or a macOS zip (Linux tarballs are
-currently unsigned; if they ever gain GPG signing, the same key would
-naturally be reused). Maintaining two keys for the same provenance claim
-would create rotation and trust-chain complexity without a corresponding
-security benefit. The `RPM_GPG_PRIVATE_KEY` secret name predates macOS zip
-signing; renaming it would require coordinated changes across multiple
-workflows. The name is historical; the key is project-wide.
+same key whether they downloaded an RPM, a DEB, or a macOS zip (plain Linux
+tarballs are currently unsigned; if they ever gain GPG signing, the same key
+would naturally be reused). Maintaining separate keys for the same provenance
+claim would create rotation and trust-chain complexity without a
+corresponding security benefit. The `RPM_GPG_PRIVATE_KEY` secret name
+predates both DEB and macOS zip signing; renaming it would require
+coordinated changes across multiple workflows. The name is historical; the
+key is project-wide.
 
 If the project ever needs per-format signing keys (for example, to support
 different rotation cadences), the migration path is: add new format-specific
@@ -306,8 +328,8 @@ boundary use the sec-team naming convention.
 
 ### Local validator scope
 
-The local validator is intentionally "Tier 1": it exercises the parts of the
-pipeline that are reproducible offline. What it does and does not cover:
+The local validator intentionally covers only the parts of the pipeline that
+are reproducible offline. What it does and does not cover:
 
 | Part | Local validator | Why |
 | --- | --- | --- |
@@ -316,12 +338,12 @@ pipeline that are reproducible offline. What it does and does not cover:
 | `rcodesign encode-app-store-connect-api-key` | yes, with `openssl`-generated ECDSA P8 | encode step is purely local, no network |
 | `rcodesign notary-submit` (notarization) | no | hardcoded `https://appstoreconnect.apple.com/notary/v2/submissions` endpoint in `app-store-connect/src/notary_api.rs`; no `--dry-run`, no env-var endpoint override |
 
-Reaching Tier 2 (running the indygreg action via `act`) or Tier 3 (mocking
-the notary HTTPS endpoint) would require more infrastructure than the
-current Tier-1 setup. Tier 1 covers ~80% of the value at ~5% of the
-complexity: any divergence between local and CI for the signing/zip/GPG
-path will surface; only Apple's notary submission itself is untested
-locally.
+The one part it cannot cover offline is Apple's notary submission itself
+(`rcodesign notary-submit`), which has to reach Apple's servers. Mocking that
+HTTPS endpoint would take more infrastructure than the rest of the validator
+combined, for the single step a real release exercises anyway. Everything
+else, any divergence between local and CI on the sign / zip / GPG path,
+surfaces locally.
 
 ### Stub Mach-O binaries in the local validator
 
@@ -368,6 +390,12 @@ revisiting the design:
   mounted `OUTPUT_DIR` or the published artifacts
 - `Import GPG key` fails fast on an empty `RPM_GPG_PRIVATE_KEY` rather than
   letting the no-op signing branch produce an unsigned release
+- each signing secret is deleted right after its last consumer, so none
+  remain on disk once the AWS credentials action and `upload-artifact` run
+- each zip's `.sig` is uploaded to S3 before the zip itself, so a partial
+  upload can never leave a consumable zip without its signature
+- the `rcodesign` tarball is verified against a repo-pinned SHA256, not the
+  upstream `*.sha256` sidecar
 - the macOS Mach-O binaries are built natively on `macos-14`; all other
   operations run on `ubuntu-24.04`
 
@@ -376,7 +404,7 @@ revisiting the design:
 The current design should be reconsidered if any of these change:
 
 - rcodesign gains a `--dry-run` flag or env-var endpoint override for
-  notarization (would enable a Tier 3 local mock)
+  notarization (would let the local validator cover notary submission too)
 - Apple migrates away from an rcodesign-compatible API (would force a fall-
   back to Apple's `notarytool` or `codesign`, which only run on macOS)
 - the security team rotates to a per-format GPG signing key (would require
@@ -404,7 +432,6 @@ The current design should be reconsidered if any of these change:
 
 ### Upstream tooling
 
-- [`indygreg/apple-code-sign-action`](https://github.com/indygreg/apple-code-sign-action) - GitHub Action wrapping rcodesign
 - [`indygreg/apple-platform-rs`](https://github.com/indygreg/apple-platform-rs) - rcodesign source; relevant code paths: `apple-codesign/src/cli/mod.rs` (CLI surface), `app-store-connect/src/notary_api.rs` (hardcoded notary endpoint)
 - [`rcodesign` documentation](https://gregoryszorc.com/docs/apple-codesign/stable/) - including [certificate management](https://gregoryszorc.com/docs/apple-codesign/stable/apple_codesign_certificate_management.html) and [signing reference](https://gregoryszorc.com/docs/apple-codesign/stable/apple_codesign_rcodesign_signing.html)
-- [Apple notary service overview](https://developer.apple.com/documentation/security/customizing_the_notarization_workflow)
+- [Apple notary service overview](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution)

.github/packaging/scripts/build-macos-zip-builder-image.sh

@@ -3,9 +3,9 @@
 # Build the macOS-zip validator Docker image with Go and rcodesign checksum
 # verification.
 #
-# Fetches the SHA256 checksum for the Go tarball from go.dev release metadata
-# and for rcodesign from its release sidecar file, then passes both to the
-# Docker build for integrity verification.
+# Fetches the SHA256 checksum for the Go tarball from go.dev release metadata,
+# uses a repo-pinned digest for rcodesign, then passes both to the Docker build
+# for integrity verification.
 #
 # Required env vars:
 #   GO_VERSION              - Go version to install (e.g., "1.24.12")
@@ -24,14 +24,28 @@ set -euo pipefail
 
 command -v jq >/dev/null 2>&1 || { echo "ERROR: jq is required but not found on PATH" >&2; exit 1; }
 
-# Map host arch to Go's and rcodesign's naming conventions
+# Map host arch to Go's naming convention, and pin the rcodesign release-tarball
+# SHA256 per arch. The digests are pinned in this repo
+# (rather than fetched from the release's own .sha256 sidecar) so a retagged or
+# replaced upstream release cannot swap the signing binary. Keep in sync with
+# APPLE_CODESIGN_SHA256 / APPLE_CODESIGN_PKG_VERSION in
+# .github/workflows/build-macos-release.yml. Digests are version-specific.
+readonly PINNED_APPLE_CODESIGN_VERSION="0.28.0"
 arch=$(uname -m)
 case "${arch}" in
-    x86_64)        goarch="amd64"; rcodesign_arch="x86_64-unknown-linux-musl" ;;
-    aarch64|arm64) goarch="arm64"; rcodesign_arch="aarch64-unknown-linux-musl" ;;
+    x86_64)        goarch="amd64"; rcodesign_checksum="d0f0e4c7915295a1e79fc8b775b354c76d621a52da4c6b841dc9f0585de06cca" ;;
+    aarch64|arm64) goarch="arm64"; rcodesign_checksum="1d3550680c0444b24b1387753f46efc7dcdb336f9001dbde4508f1c58da90b81" ;;
     *) echo "Unsupported arch: ${arch}" >&2; exit 1 ;;
 esac
 
+# The pinned digests above are only valid for one rcodesign version. Fail loudly
+# if the requested version has drifted, rather than verifying against the wrong
+# digest.
+if [[ "${APPLE_CODESIGN_VERSION}" != "${PINNED_APPLE_CODESIGN_VERSION}" ]]; then
+    echo "ERROR: no pinned rcodesign digest for version ${APPLE_CODESIGN_VERSION} (pinned: ${PINNED_APPLE_CODESIGN_VERSION}); update the digests in $(basename "$0")" >&2
+    exit 1
+fi
+
 # ── Go checksum ──────────────────────────────────────────────────────
 
 go_filename="go${GO_VERSION}.linux-${goarch}.tar.gz"
@@ -45,21 +59,7 @@ if [[ -z "${go_checksum}" || "${go_checksum}" == "null" ]]; then
     exit 1
 fi
 echo "Go checksum: ${go_checksum}"
-
-# ── rcodesign checksum ───────────────────────────────────────────────
-
-rcodesign_filename="apple-codesign-${APPLE_CODESIGN_VERSION}-${rcodesign_arch}.tar.gz"
-# The tag uses a slash separator (apple-codesign/<ver>) that must be URL-
-# encoded as %2F in the download path.
-rcodesign_sha_url="https://github.com/indygreg/apple-platform-rs/releases/download/apple-codesign%2F${APPLE_CODESIGN_VERSION}/${rcodesign_filename}.sha256"
-echo "Fetching SHA256 checksum for ${rcodesign_filename}..."
-rcodesign_checksum=$(curl -fsSL "${rcodesign_sha_url}" | awk '{print $1}')
-
-if [[ -z "${rcodesign_checksum}" ]]; then
-    echo "ERROR: Could not fetch checksum for ${rcodesign_filename} from ${rcodesign_sha_url}" >&2
-    exit 1
-fi
-echo "rcodesign checksum: ${rcodesign_checksum}"
+echo "rcodesign checksum (pinned): ${rcodesign_checksum}"
 
 # ── Build ───────────────────────────────────────────────────────────
 

.github/packaging/scripts/build-macos-zip.sh

@@ -108,6 +108,9 @@ done
 # branching (same path RPM/DEB packaging uses). The production script
 # (build-zip-pkg.sh) reads GPG_KEY_FILE and GPG_PASSPHRASE.
 
+# setup_gpg (called below) materializes the signing key at NFPM_SIGNING_KEY:
+# it writes the freshly-generated ephemeral key there, or copies the provided
+# key file to that path. Everything downstream reads the key from this path.
 INPUT_GPG_KEY_FILE="${GPG_KEY_FILE:-}"
 export NFPM_SIGNING_KEY="${STAGE}/gpg-signing-key.asc"
 export GPG_PASSPHRASE="${GPG_KEY_PASSPHRASE:-}"