security(release): move signing secrets from repo scope to release/nightly environments

[harshitsinghbhandari]

Problem

The six macOS signing secrets (CSC_LINK, CSC_KEY_PASSWORD, APPLE_SIGNING_IDENTITY, APPLE_API_KEY_BASE64, APPLE_API_KEY_ID, APPLE_API_ISSUER) are repository-level Actions secrets. The release environment (required reviewers: @harshitsinghbhandari, @neversettle17-101, @somewherelostt, @Vaibhaav-Tiwari, @Priyanchew) gates the stable release workflow, but the gate can be bypassed: any write-access user can push a desktop-v* tag whose commit edits frontend-release.yml to drop the environment: release line. The workflow runs from the tagged commit, so it would build ungated and still read the repo-level secrets, producing a fully signed stable release with no approval.

Environment secrets close this: a gate-stripped workflow gets no signing secrets at all.

Constraint: nightly needs the same secrets

frontend-nightly.yml signs macOS builds in two jobs (release matrix and release-intel) using the same six secrets, runs unattended on a daily cron, and must not require manual approval.

Plan

Admin steps (AgentWrapper account; secrets cannot be copied, values must be re-entered from the original signing materials):

• Add the six secrets to the existing release environment (Settings > Environments > release). The stable workflow's signing jobs already declare environment: release, no YAML change needed.
• Create a nightly environment: no required reviewers, deployment branch policy = selected branches, main only. Add the same six secrets.
• While in Settings: confirm main blocks direct pushes by write users (the nightly environment trusts code on main; its branch policy is the only thing keeping a tampered workflow on another ref away from the secrets).

Repo change:

• Add environment: nightly to the two signing jobs in frontend-nightly.yml (small PR, to merge after the environments exist).

Cleanup, only after one nightly and ideally one stable release go green on environment secrets:

• Delete the six repo-level secrets.

Ordering matters: deleting the repo-level secrets before the environments and YAML are in place makes the next nightly ship unsigned or fail.

Out of scope (accepted for now)

Any write user can still create a GitHub release directly (gh release create) without any workflow; it would be unsigned but becomes releases/latest. Restricting v*/desktop-v* tag creation via rulesets cannot allowlist individual users on a user-owned repo, so this is a trust boundary until the repo moves to an org.

🤖 Generated with Claude Code