Protect release automation

The moment releases run in CI, your pipeline holds real power: a certificate that speaks in your name and credentials that talk to Apple. Protect that job differently from ordinary tests.

The first rule is separation. Pull-request jobs run tests on unreviewed code — code anyone can propose. They must never see signing keys or notarization credentials, or a malicious pull request can exfiltrate them. Expose release secrets only to protected workflows: a protected tag, a manually approved environment, a release branch with review requirements.

Store secrets in the platform’s secret store, never in the repository. On the runner, import the certificate into a dedicated temporary keychain:

security create-keychain -p "$KEYCHAIN_PASSWORD" build.keychain
security import certificate.p12 -k build.keychain \
  -P "$CERT_PASSWORD" -T /usr/bin/codesign
security unlock-keychain -p "$KEYCHAIN_PASSWORD" build.keychain

And never echo secret values. A single set -x in the wrong script prints your certificate password into a build log that outlives the job.

Here’s the CI failure everyone meets once: codesign dies with errSecInternalComponent. The message is useless, but the cause is almost always a locked keychain — headless runners don’t get the unlock that logging in normally provides. The security unlock-keychain call above, plus security set-key-partition-list to let codesign use the key without a UI prompt, is the fix.

Pin the toolchain. Select the exact Xcode version the release needs and pin dependency versions, so the same tag produces the same bytes next month.

Then make every artifact traceable. Record the source commit, the workflow run, the version and build, the artifact’s SHA-256, the signing identity, and the notarization submission identifier.

Keep one human in the loop. Automation should assemble the release; a person reviews the version and the notes and presses publish. Automation removes repetition, not accountability.