Context
The Apple signing/notarization secrets (APPLE_CERTIFICATE, APPLE_CERTIFICATE_PASSWORD, APPLE_SIGNING_IDENTITY, APPLE_API_KEY, APPLE_API_ISSUER, APPLE_API_PRIVATE_KEY, + notarization) are currently repository-scoped — available to any workflow on any branch. release-macos.yml uses them directly, without an environment: gate.
Risk (dormant — no present exploit)
A future collaborator with push access could add/modify a workflow on a branch that omits the reviewer-gated environment: and exfiltrate the signing cert. The repo currently has a single admin/collaborator (silverstein), so there is no present exploit. This is a best-practice gap about a future threat model (adding collaborators), not a live vulnerability. It has existed since release-macos.yml was created.
Why deferred from the conversation-trust landing
Surfaced during the trust-feature landing. The new signed-dev-acceptance workflow is already environment-gated and safe for a single-admin repo. Migrating all signing secrets to environment scope + modifying release-macos.yml (production release signing) + a temporary admin-token-in-CI migration + deleting the repo-scoped copies is a separate security-infra change that would risk the release pipeline if bundled onto the feature freeze. Deferred to be done deliberately, in isolation, with release-pipeline testing afterward.
Proposed remediation (design from the minutes:2 security review — preserved so it isn't lost)
- One-time,
main-only, reviewer-gated migration workflow.
- Add
environment: release-signing to release-macos.yml.
- Configure
release-signing + signing-secret-migration environments.
- Place a short-lived admin token only in the migration environment.
- Server-side copy the 7 repo secrets into
release-signing (+ the 3 cert values into signed-dev-acceptance), verify names, then delete the repository-scoped copies.
- Delete the migration token immediately after.
- Strengthen the signed-acceptance policy fixtures against payload / local-action execution.
- Test
release-macos.yml end-to-end (a dry-run/test release) after migration before relying on it.
Trigger
Do this before adding any second collaborator or admin to the repo — that is the event that activates the risk. Until then it is dormant.
Context
The Apple signing/notarization secrets (
APPLE_CERTIFICATE,APPLE_CERTIFICATE_PASSWORD,APPLE_SIGNING_IDENTITY,APPLE_API_KEY,APPLE_API_ISSUER,APPLE_API_PRIVATE_KEY, + notarization) are currently repository-scoped — available to any workflow on any branch.release-macos.ymluses them directly, without anenvironment:gate.Risk (dormant — no present exploit)
A future collaborator with push access could add/modify a workflow on a branch that omits the reviewer-gated
environment:and exfiltrate the signing cert. The repo currently has a single admin/collaborator (silverstein), so there is no present exploit. This is a best-practice gap about a future threat model (adding collaborators), not a live vulnerability. It has existed sincerelease-macos.ymlwas created.Why deferred from the conversation-trust landing
Surfaced during the trust-feature landing. The new
signed-dev-acceptanceworkflow is already environment-gated and safe for a single-admin repo. Migrating all signing secrets to environment scope + modifyingrelease-macos.yml(production release signing) + a temporary admin-token-in-CI migration + deleting the repo-scoped copies is a separate security-infra change that would risk the release pipeline if bundled onto the feature freeze. Deferred to be done deliberately, in isolation, with release-pipeline testing afterward.Proposed remediation (design from the minutes:2 security review — preserved so it isn't lost)
main-only, reviewer-gated migration workflow.environment: release-signingtorelease-macos.yml.release-signing+signing-secret-migrationenvironments.release-signing(+ the 3 cert values intosigned-dev-acceptance), verify names, then delete the repository-scoped copies.release-macos.ymlend-to-end (a dry-run/test release) after migration before relying on it.Trigger
Do this before adding any second collaborator or admin to the repo — that is the event that activates the risk. Until then it is dormant.