From a49b89e2c285b78da5aa3b4312f5513d2eefd5c7 Mon Sep 17 00:00:00 2001 From: d0ubl3g <48954024+d0ubl3g@users.noreply.github.com> Date: Thu, 15 Oct 2026 19:10:50 +0200 Subject: [PATCH] Make the macOS signing check optional in the release-signing steps The default procedure to enable macOS signing is to store the nine secrets and set MACOS_SIGNING_ENABLED to true: the next release signs and notarizes, and its draft is published only after the macOS job and its checks pass. The signing check workflow stays documented as an optional way to check the secrets before a release, with its two preconditions. Refs #50 Signed-off-by: d0ubl3g <48954024+d0ubl3g@users.noreply.github.com> --- docs/release-signing.md | 31 +++++++++++++++++-------------- 1 file changed, 17 insertions(+), 14 deletions(-) diff --git a/docs/release-signing.md b/docs/release-signing.md index 10790ef..945e22d 100644 --- a/docs/release-signing.md +++ b/docs/release-signing.md @@ -121,20 +121,23 @@ checks the binary's notarization online on first run. See `true` and a secret is missing, the job fails and names it. When the variable is not `true`, the release still builds and publishes, the macOS binary is not signed or notarized, and the run summary says so. -- **Checking the secrets without a release.** The **macOS signing check** workflow - (`macos-signing-check.yml`, started by hand) is bound to the same environment, so it needs the - same approval. It signs and notarizes a throwaway test executable and package with the stored - secrets, verifies them like a release does, and uploads nothing. It fails, listing the names, if a - secret is missing. +- **Checking the secrets without a release (optional).** The **macOS signing check** workflow + (`macos-signing-check.yml`, started by hand) signs and notarizes a throwaway test executable and + package with the stored secrets, verifies them like a release does, and uploads nothing. It fails, + listing the names, if a secret is missing. It is bound to the same environment, so it needs the + same approval, and it has two preconditions: the workflow must be on the default branch to be + dispatched, and the environment accepts deployments from `v*` tags only, so a repository + administrator adds `main` to its allowed branches for the check and removes it afterwards. To enable it, a maintainer with the right to change the environment: 1. stores the nine secrets in the `release-signing` environment; -2. lets the **macOS signing check** run: the environment accepts deployments from `v*` tags only, so - a repository administrator adds `main`, where the workflow runs, to its allowed branches for the - check and removes it afterwards; -3. runs **macOS signing check** and reads its summary: it must pass; -4. sets the repository variable `MACOS_SIGNING_ENABLED` to `true`. +2. sets the repository variable `MACOS_SIGNING_ENABLED` to `true`. + +The next release signs and notarizes the macOS binaries, and its draft is published only after the +macOS job and its checks pass. If signing or notarization fails, the release run fails and nothing +is published, so the first signed release is itself the test. To check the secrets before that +release, run the optional **macOS signing check** workflow as described above. The first release signed this way is the first one whose run summary says "macOS signing: signed and notarized". Releases before it are not signed with a Developer ID. To @@ -301,10 +304,10 @@ that the release workflow did not sign. revokes their notarization tickets, which the maintainers can ask Apple to do for files known to be malicious. 3. **Replace.** Create new certificates and a new API key, store them as the secrets listed under - [Developer ID (macOS)](#developer-id-macos), run the **macOS signing check** workflow, and set - `MACOS_SIGNING_ENABLED` back to `true`. Then publish a new patch release of each - [supported version](../SECURITY.md#supported-versions) through the normal release process: a - published file cannot be signed again in place. + [Developer ID (macOS)](#developer-id-macos), optionally run the **macOS signing check** + workflow, and set `MACOS_SIGNING_ENABLED` back to `true`. Then publish a new patch release of + each [supported version](../SECURITY.md#supported-versions) through the normal release process: + a published file cannot be signed again in place. 4. **Tell users** as in the Windows section above (security advisory, notice in the README, release notes), naming the affected versions and the Team ID, and update this document and [verifying-releases.md](verifying-releases.md#6-releases-after-a-signing-change).