Resolve notary profile deterministically from the signing keychain - #90
Merged
Conversation
The blurt-notary credentials live in the dedicated blurt-signing keychain, which stays locked at rest by design. The preflight ran the notarytool profile check before unlock_signing_keychain, and since notarytool reads non-interactively it couldn't see the profile in a locked keychain — so it died "profile not found" before ever reaching the unlock step, never prompting to load the keychain. Move the check after the unlock so a genuine "not found" really means the profile was never stored. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR fixes a release-script failure where the blurt-notary keychain profile could not be found because the dedicated blurt-signing keychain was still locked when notarytool was invoked. It reorders the preflight so the signing keychain is unlocked first, making the subsequent notary-profile check meaningful in non-interactive contexts.
Changes:
- Unlock the dedicated signing keychain before running
xcrun notarytool history --keychain-profile ...in the preflight. - Add inline commentary documenting why the ordering matters for
notarytoolprofile visibility.
Comments suppressed due to low confidence (1)
scripts/release-build.sh:195
notarytool historyfailures are currently always reported as "profile not found" because all output is discarded and thediemessage assumes a specific cause. Capture stderr and include it (and optionally hint at--keychain "$SIGNING_KEYCHAIN") so non-profile failures (network/service/auth) are diagnosable and not misclassified.
xcrun notarytool history --keychain-profile "$NOTARY_PROFILE" >/dev/null 2>&1 \
|| die "notarytool profile '$NOTARY_PROFILE' not found. Run: xcrun notarytool store-credentials $NOTARY_PROFILE --apple-id <you@example.com> --team-id $TEAM_ID --password <app-specific-password>"
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+189
to
+193
| # Check the notary profile only AFTER unlocking the signing keychain: the | ||
| # blurt-notary credentials live in that keychain, and notarytool runs | ||
| # non-interactively, so against a still-locked keychain it can't read the | ||
| # profile item and reports it as missing. Unlock first, then a genuine | ||
| # "not found" here really means the profile was never stored. |
alexkroman
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The release preflight resolved the
blurt-notarynotary profile via the keychain search list (no--keychain), which is non-deterministic: notarytool picks the profile from whichever keychain on the search list happens to hold one. On this machine the profile exists only in an incidental electron-builder keychain — not in login and not in the dedicatedblurt-signingkeychain where the design intends it to live. So the lookup succeeded or failed depending purely on search-list order and lock state, surfacing as an intermittentnotarytool profile 'blurt-notary' not found.This makes the lookup deterministic:
NOTARY_KEYCHAIN=(--keychain "$SIGNING_KEYCHAIN")once the signing keychain is unlocked, and run the preflight check after the unlock.historycheck and thesubmit/logcalls innotarize()to that keychain, so the whole pipeline uses the same, intended profile.${arr[@]+"${arr[@]}"}so the empty case is safe underset -uon macOS bash 3.2.--keychain; the release skill's preconditions say the same.Operator action required: store the profile in the signing keychain:
xcrun notarytool store-credentials blurt-notary --keychain ~/Library/Keychains/blurt-signing.keychain-db --apple-id <you> --team-id Y54ZB9JF63 --password <app-specific-pw>Note: a separate blocker exists — Apple currently returns
403 — a required agreement is missing or has expired; the account's Developer Program License Agreement must be re-signed before notarization will succeed.Verification
shellcheck -x scripts/release-build.sh— clean (exit 0).bash -n scripts/release-build.shunder/bin/bash3.2.57 — parses.${arr[@]+"${arr[@]}"}is safe underset -euo pipefailon bash 3.2.🤖 Generated with Claude Code