[build-tools] Fix iOS local build on macOS Tahoe — drop -v from find-identity in findIdentitiesByTeamId#3679
Open
kearnsm293-afk wants to merge 2 commits intoexpo:mainfrom
Conversation
…identity in findIdentitiesByTeamId
`Keychain.findIdentitiesByTeamId` runs `security find-identity -v -s
"(<teamId>)" <buildKeychainPath>` to verify that the dist cert was
imported into the freshly-created build keychain. The `-v` ("valid
identities only") flag requires the full trust chain (dist cert ->
Apple WWDR Intermediate -> Apple Root CA) to resolve from the
keychain(s) in the search list. The build keychain only holds the
cert + private key; Apple Root CA lives in
/Library/Keychains/System.keychain. `security find-identity` does
not aggregate trust resolution across keychains passed as positional
args — only `security list-keychains -s` does, and that's
session-wide and would mutate the user's environment.
On macOS 26 (Tahoe), this caused `find-identity -v` to return 0
identities even when the cert+key were correctly imported, falsely
tripping `ensureCertificateImported` with "Distribution certificate
... hasn't been imported successfully".
Dropping `-v` fixes the presence check across macOS versions.
Codesign performs its own trust resolution downstream via
Security.framework (which does aggregate across keychains), so
signing still succeeds.
Existing integration test
`packages/build-tools/src/ios/credentials/__integration-tests__/keychain.test.ios.ts`
("shouldn't throw any error if the certificate has been imported
successfully") covers this scenario and now passes on Tahoe.
Closes expo#3678
|
Subscribed to pull request
Generated by CodeMention |
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.
Why
Closes #3678. On macOS 26 (Tahoe),
eas build --profile development --platform ios --localfails atPrepare credentialswithDistribution certificate ... hasn't been imported successfullyeven when the cert+key are correctly imported into the build keychain.Keychain.findIdentitiesByTeamIdruns:The
-v("valid identities only") flag requires the full trust chain (dist cert → Apple WWDR Intermediate → Apple Root CA) to resolve from the keychain(s) in the search list. The build keychain (created inKeychain.create()) only holds the cert + private key; Apple Root CA lives in/Library/Keychains/System.keychainand Apple WWDR G3 lives in the user's login keychain.security find-identitydoes not aggregate trust resolution across keychains passed as positional args — onlysecurity list-keychains -sdoes, and that change would be session-wide and undesirable.On macOS 26 (Tahoe), this trust gate causes
find-identity -v -s "(<teamId>)" <buildKeychainPath>to return 0 identities even when the cert+key were correctly imported, falsely trippingensureCertificateImported.How
Drop
-vfrom thefind-identitycall. The remaining flags (-s "(<teamId>)" <buildKeychainPath>) still constrain the match to the right team and keychain, so theincludes(fingerprint)check inensureCertificateImportedcorrectly answers "is the cert+key pair present in this keychain?" The cert appears in the output annotated(CSSMERR_TP_NOT_TRUSTED)— that's expected and ignored. Codesign performs its own trust resolution downstream viaSecurity.framework(which does aggregate across keychains), so signing still succeeds end-to-end.The change is one line in
packages/build-tools/src/ios/credentials/keychain.tsplus a comment block explaining the reasoning so a future reader doesn't add-vback.Test Plan
packages/build-tools/src/ios/credentials/__integration-tests__/keychain.test.ios.ts("shouldn't throw any error if the certificate has been imported successfully") covers exactly this scenario. It currently fails on macOS 26 (Tahoe) due to this bug; the fix makes it pass.eas build --profile development --platform ios --localagainst an Expo-managed dist cert + ad-hoc provisioning profile completes successfully on macOS 26.0 (Tahoe) with the patch applied. Produces a signed.ipathat installs and runs on a registered iOS 26 device.-vis strictly more permissive in whatfind-identityreports back. On systems where-vworked (older macOS, or systems where Apple Root CA happens to be visible in the build keychain's effective search list), the same cert+key pair still appears in the output without-v. Theincludes(fingerprint)check passes in both cases.Checklist
## main→### 🐛 Bug fixes. (PR URL placeholder will be replaced with the real PR number once this is opened.)[package] Descriptionformat.