fix(desktop): rebuild the ASC API key PEM before notarizing - #14560
Merged
Conversation
notarytool rejects a malformed .p8 with a bare `invalidPEMDocument`, which says nothing about what was wrong — the Mac build hit exactly this once the signing cert was fixed and it finally got far enough to notarize. Secret stores routinely mangle PEMs, either flattening the newlines to literal \n or stripping them entirely, and the previous code trusted the stored formatting as long as the BEGIN marker was present. Pull out the base64 body and rebuild the PEM instead, so all the usual shapes converge on a valid key, and throw a message that names the actual problem when the secret isn't a PKCS#8 key at all. Verified against six mangling modes (raw, literal \n, no newlines, CRLF, and base64 of the first two) plus a garbage input, checking each result parses with `openssl pkey -check`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
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
1 participant
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.
Problem
With the Developer ID signing cert replaced, the Mac desktop build now signs successfully and reaches notarization for the first time — where it fails:
invalidPEMDocumentmeans notarytool could not parse the.p8written fromAPP_STORE_CONNECT_API_KEY_KEY. The key itself is healthy — App Store Connect shows the team key active and in use.writeApiKeyFiletrusted the stored formatting whenever theBEGIN PRIVATE KEYmarker was present. Secret stores commonly flatten PEM newlines to literal\nor strip them altogether, both of which keep the marker while producing a file notarytool rejects.Fix
Extract the base64 body and rebuild the PEM at 64-column wrapping, so every common storage shape converges on a valid key. When the secret isn't a PKCS#8 key at all, throw an error that says so instead of writing a broken file and letting notarytool report a generic parse failure.
Testing
Generated a P-256 PKCS#8 key (same shape as an App Store Connect
.p8) and ran each mangling through the normalizer, checking the result withopenssl pkey -check:\nescapes\n-escaped PEMNote this cannot be verified in CI without merging, since
desktop-build-maconly runs onmainbehind the production gate.🤖 Generated with Claude Code