moi aussi je me suis battu. Rien n'a aidé jusqu'à ce que j'ai essayé la suggestion sur http://devnet.jetbrains.com/thread/311971 . Merci ashish agrawal!

Connectez votre utilisateur de build via L'accès GUI et ouvrez le porte-clés. Sélectionnez votre clé privée de signature, cliquez avec le bouton droit de la souris, sélectionnez Obtenir des informations, passez à L'onglet Contrôle d'accès et sélectionnez "Permettre à toutes les applications d'accéder à cet élément".

Aucune des autres réponses a fonctionné pour moi.

ce qui m'a finalement sauvé était this post

pour résumer, cela peut être causé par un délai par défaut de 5 minutes, qui déclenchera cette erreur après une longue compilation.

pour fixer:

security set-keychain-settings -t 3600 -l ~/Library/Keychains/login.keychain

essayez d'appeler security unlock-keychain et codesign comme une commande en ligne. Cela m'a aidé. Quelque chose comme:

security unlock-keychain -p <password> /Users/<user>/Library/Keychains/login.keychain && codesign --force --verify --verbose --sign "<certificate id>" <app name>

mettez vos clés dans le porte-clés du système

Donc, c'est la commande qui fonctionne. -A est d'empêcher Mac de demander le mot de passe. L'importation du système.trousseau ne nécessite pas d'interface graphique.

sudo security import <cert.p12> -k "/Library/Keychains/System.keychain" -P <passphrase> -A

mon porte-clés était verrouillé. Il a résisté mes avances pour changer ce fait...

Keychain Access -> Keychain First Aid -> Repair , et voilà !

ouvrir le porte-clés n'est pas suffisant. Vous devez également configurer l'accès à clé privée pour "permettre à toutes les applications d'accéder à cet élément". Et pour le faire en ligne de commande nécessite réimportation la clé. Donc prendre les choses à la fois:

déverrouille le porte-clés de connexion s'il est verrouillé. Il ne devrait pas être verrouillé, mais de toute façon voici comment vous faites cela:

security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "~/Library/Keychains/login.keychain"

si pour une raison quelconque votre machine de construction a le porte-clés de connexion verrouillé, et vous ne voulez pas exposez ce mot de passe dans un script, puis vous devriez utiliser un porte-clés différent. Vous pouvez en créer un sur place et l'utiliser dans la commande précédente et la suivante. Pour en créer un sur place:

security create-keychain -p 'temporaryPassword' MyKeychain.keychain
security list-keychains -d user -s login.keychain MyKeychain.keychain

ensuite, importez vos certificats et les clés privées associées dans le porte-clés de connexion en utilisant le paramètre-a. Notez que vous n'avez pas besoin de sudo pour tout cela...

security import <cert.p12> -k "~/Library/Keychains/login.keychain" -P <passphrase> -A

le paramètre-A est ce qui fera que votre clé privée sera définie à "Permettre à toutes les applications d'accéder à cet article "

donc en utilisant tous ceux-ci vous devriez être en mesure de faire un script qui installe le certificat requis pour construire une version ipa et signer sans prompt. Vous pouvez stocker la .P12 fichier dans votre repo, de sorte que n'importe quelle machine peut construire votre ipa sans avoir besoin de configuration manuelle.

Importez vos clés dans le porte-clés du système. Vous pouvez utiliser cette commande:

sudo security import YourKey.p12 -k /Library/Keychains/System.keychain -P PasswordToYourKey -T /usr/bin/codesign

pour moi rien n'a fonctionné semble devoir réinstaller Xcode à nouveau. Jenkins continue de faire la même erreur. Vous gagneriez beaucoup de temps en déplaçant l'installation de Xcode à la Corbeille et en réinstallant. Assurez-vous d'exécuter la commande codesign depuis la ligne de commande au moins une fois.

même après si vous obtenez la même erreur essayer de définir 'déverrouiller Porte-clés?'propriété au sein de Jenkins et donner le chemin à votre login.trousseau sous /Users/${USER}/Bibliothèque/Keychains/login.porte-clés

j'espère que Dieu sera avec vous après cela.

dans mon cas, cela a été causé par un porte-clés créé avec un délai par défaut de 300s et une longue compilation xcode d'une durée de plus de 300s. La solution, pour moi, était d'invoquer:

security set-keychain-settings -t <longer timeout in seconds> <keychain>

immédiatement après la création du porte-clés temporaire.

j'ai passé en revue toutes ces suggestions et j'avais encore des problèmes à utiliser le gym de fastlane dans un travail de Jenkins. J'ai fait installer le certificat et déverrouiller le porte-clés, et j'ai pu coder sur l'esclave quand j'ai lancé manuellement la commande codesign sur la ligne de commande.

comme solution de contournement, si Jenkins se connecte à l'esclave en utilisant JNLP au lieu de SSH, vous pourrez co-concevoir.

alors j'ai essayé toutes les réponses ici et quelque chose ne collait pas vraiment. Finalement j'ai compris quand j'ai redémarré mon service de CI, il fonctionnait sous un utilisateur différent que j'avais prévu. Changer pour l'utilisateur qui avait effectivement accès à la clé dans leur chaîne de connexion a tout corrigé. Ce n'est peut-être pas un problème courant, mais j'ai voulu documenter la raison précise de cette erreur, au cas où cela arriverait à d'autres.

pour moi ça arrive quand il y a un deuxième porte-clés ajouté manuellement et qu'il est verrouillé. Pour une raison quelconque codesign essaie d'accéder au porte-clés verrouillé et échoue même si les certificats sont dans le porte-clés de connexion (et est déverrouillé). Déverrouiller le second résout le problème. N'a tout simplement pas de sens pour moi.

utiliser la sécurité pour créer un porte-clés pour /usr/bin/codesign

importer le certificat et le faire fonctionner avec codesign programmatically n'est pas une question d'utiliser des clés de connexion ou de système ou de prier un dieu de codesign. Vous avez juste besoin d'avoir le bon ensemble d'autorisations. Je recommande la création d'un nouveau porte-clés spécifiquement pour des fins de co-conception.

ces jours-ci pour obtenir codesign pour ne pas donner un errSecInternalComponent vous devez obtenir la liste des partitions (ACLs) est correcte. Je traverserai les marches:

créer le porte-clés

security create-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"

à ce point le porte-clés est déverrouillé mais n'apparaîtra pas dans Keychain Access .

ajouter le nouveau porte-clés à la liste de recherche

security list-keychains -s "${KEYCHAIN_NAME}" "${OLD_KEYCHAIN_NAMES[@]}"

ajouter le nouveau porte-clés à la liste. Si vous ne prenez pas d'abord la liste originale de list-keychains vous n'aurez plus login.keychain dans votre recherche de la liste.

déverrouiller le porte-clés

security unlock-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"

c'est redondant si vous avez créé le porte-clés ci-dessus, mais si le porte-clés existait déjà il est nécessaire.

Supprimer les paramètres par défaut dans le Trousseau

security set-keychain-settings "${TESTING_KEYCHAIN}"

en ne spécifiant aucun argument, cela définira le délai de verrouillage automatique à illimité et supprimera le verrouillage automatique sur le sommeil.

importer vos certs de signature d'un .p12

security import "${DIST_CER}" -P "${CERTIFICATE_PASSWORD}" -k "${KEYCHAIN_NAME}" -T /usr/bin/codesign

Importer les certificats et donne codesign accès par le biais de la -T option.

placer L'ACL sur le porte-clés

security set-key-partition-list -S apple-tool:,apple: -s -k "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"

C'est une exigence que beaucoup de gens manquent. Vous pouvez voir ce que fait macOS en utilisant dump-keychain. Qui, dans le cas d'un codesigning, exige apple: et apple-tool: . -s fait référence aux certificats de signature.

Gitlab-Runner, Jenkins et similaires

une chose très importante pour tout coureur ou système de construction de type CI est de s'assurer que le processus est lancé à partir de launchd correctement. Assurez-vous que votre plaquette contient <SessionCreate> </true> .

ne pas faire correspondre correctement le propriétaire du porte-clés avec le processus de construction et de s'assurer qu'une session de sécurité est créée résultera de toutes sortes de maux de tête. Diagnostiquement parlant, vous pouvez introduire list-keychains et voir si le de sortie correspond à vos attentes.

C'est de la launchd.plist l'homme-page:

SessionCreate <boolean>

Cette clé spécifie que le travail doit être généré dans une nouvelle sécurité session d'audit plutôt que la session par défaut pour le contexte is belongs de. Voir auditon(2) pour plus de détails.

UserName <string>

cette touche optionnelle spécifie l'utilisateur pour exécuter la tâche sous. Cette clé est seulement applicable pour les services qui sont chargés dans le système privilégié domaine.

GroupName <string>

Cette clé spécifie le groupe pour exécuter le travail. Cette clé est seulement applicable pour les services qui sont chargés dans le système privilégié domaine. Si Le Nom D'Utilisateur est définie et GroupName est pas, alors le groupe sera ensemble pour le groupe principal de l'utilisateur.

enfin codesign

vous pouvez rechercher le hachage des certificats de signature en utilisant find-identity

security find-identity -p codesigning -v

Codesign un cadre, dylib, etc.

/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" "$SIGNABLE"

Codesign l'app bundle

/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" --entitlements entitlements.xcent "$SIGNABLE"

notes finales - si vous regardez comment Xcode fait il ils mettent CODESIGN_ALLOCATE pour utiliser celui contenu dans Xcode, pas dans /usr/bin .

export CODESIGN_ALLOCATE="$( xcrun --find codesign_allocate )"

le chemin de recherche est défini à ${PLATFORM_PATH}:${TOOLCHAIN_PATH}:${PATH} , où le chemin de plate-forme est le répertoire /usr/bin pour le SDK cible donné et TOOLCHAIN_PATH est le /usr/bin pour les outils Xcode host.

après avoir essayé un certain nombre des solutions ci-dessus. J'ai réalisé que l'un des facteurs que j'avais, c'était que je commençais la construction en utilisant la Console ionique. Quand je suis revenu à construire à partir de L'application Terminal, Tout a bien fonctionné.