Notre build automatisé fonctionne sur Jenkins. La construction elle-même s'exécute sur des esclaves, les esclaves étant exécutés via SSH.

J'obtiens une erreur:

00:03:25.113 [codesign-app] build/App.app: User interaction is not allowed.

J'ai essayé toutes les suggestions que j'ai vues jusqu'à présent dans d'autres articles ici:

• Utiliser le trousseau de déverrouillage de sécurité immédiatement avant de signer pour déverrouiller le trousseau.
• Déplacement de la clé de signature dans son propre trousseau.
• Déplacement de la clé de signature dans le trousseau de connexion.
• Déplacement de la clé de signature dans le trousseau du système.
• Définition manuelle de list-keychains uniquement sur le trousseau contenant la clé.

Dans tous les cas, j'obtiens la même erreur.

Pour tenter de diagnostiquer le problème, j'ai essayé d'exécuter la commande "security unlock-keychain" sur mon terminal local et j'ai constaté qu'elle ne déverrouille pas réellement le trousseau - si je regarde dans Keychain Access, le symbole de verrouillage est toujours là. C'est le cas que je passe le mot de passe sur la ligne de commande ou que je le laisse me le demander. Le déverrouillage du même trousseau à l'aide de l'interface graphique me demandera le mot de passe, puis le déverrouillera. De plus, si j'exécute "security lock-keychain", je le fais voir la serrure à clé immédiatement après l' exécution de la commande. Cela me fait penser que déverrouiller le trousseau ne fonctionne pas réellement. J'ai le même comportement sur Lion (que nous utilisons pour les esclaves de construction) et Mavericks (sur lequel je développe.)

Ensuite, j'ai essayé d'ajouter -v à toutes les commandes de sécurité:

list-keychains "-d" "system" "-s" "/Users/tester/.secret/App.keychain"
Listing keychains to see if it was added: ((
        "/Library/Keychains/System.keychain"
))
unlock-keychain "-p" "**PASSWORD**" "/Users/tester/.secret/App.keychain"
build/App.app: User interaction is not allowed.

À partir de là, il semblerait que les porte-clés de liste ne fonctionnent pas. Peut-être que ni l'un ni l'autre ne fonctionne. : /

Il y a une question similaire ici . La solution est intéressante - définissez "SessionCreate" sur true dans launchctl. Mais je ne m'appuie pas sur le maître - mon processus de construction est lancé à partir de SSH sur une machine de construction esclave. Peut-être existe-t-il un moyen en ligne de commande de faire ce que fait launchctl lorsque vous exécutez "SessionCreate"?

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

Connectez votre utilisateur de build via l'interface graphique et ouvrez Keychain Access. Sélectionnez votre clé privée de signature, cliquez avec le bouton droit de la souris, choisissez Obtenir des informations, passez à l'onglet Contrôle d'accès et sélectionnez «Autoriser toutes les applications à accéder à cet élément».

Eh bien, je suppose que je peux répondre à ma propre question aujourd'hui, car après y avoir poignardé pendant deux jours et demi, l'une des choses que j'ai essayées semble avoir fonctionné. Je vais juste m'éloigner de cela maintenant et j'espère que cela continuera à fonctionner.

Essentiellement, il semble que cela ne fonctionne -d systempas réellement. Donc, beaucoup de réponses à d'autres questions ici devraient probablement être mises à jour pour refléter cela.

security -v list-keychains -s "$KEYCHAIN" "$HOME/Library/Keychains/login.keychain"
security list-keychains # so we can verify that it was added if it fails again
security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN"
codesign --sign "$SIGNER_IDENTITY" --force --signature-size 9600 \
         --resource-rules src/AppResourceRules.plist --timestamp --verbose \
         "$APP"

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

Ce qui m'a finalement sauvé, c'est ce post

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

Pour réparer:

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

Essayez d'appeler security unlock-keychainet en codesigntant que commande sur une 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>

Utilisation de la sécurité pour créer un trousseau pour / usr / bin / codesign

Importer le certificat et le faire fonctionner avec la conception de code par programme ne consiste pas à utiliser la connexion ou les porte-clés système ou à prier un dieu de la conception de code. Vous devez simplement disposer des autorisations appropriées. Je recommande de créer un nouveau trousseau spécifiquement à des fins de conception de code.

Ces jours-ci, pour arriver codesignà ne pas produire un, errSecInternalComponentvous devez obtenir la liste de partitions (ACL) correcte. Je vais parcourir les étapes:

Créer le trousseau

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

à ce stade, le trousseau est déverrouillé mais n'apparaîtra pas Keychain Access.

Ajouter le nouveau trousseau à la liste de recherche

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

Ajoutez le nouveau trousseau à la liste. Si vous ne récupérez pas d'abord la liste d'origine, list-keychainsvous ne l'aurez plus login.keychaindans votre liste de recherche.

Déverrouillez le trousseau

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

Ceci est redondant si vous avez créé le trousseau ci-dessus, mais si le trousseau existait déjà, il est nécessaire.

Supprimer les paramètres par défaut du trousseau

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

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

Importez vos certificats de signature à partir d'un .p12

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

Importez les certificats et donne codesignaccès via l' -Toption.

Définissez l'ACL sur le trousseau

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. Ce qui dans le cas de la codification nécessite apple:et apple-tool:. -sfait référence à la signature de certificats.

Gitlab-Runner, Jenkins et autres

Une chose très importante pour tout coureur de type CI ou système de construction est de s'assurer que le processus est démarré launchdcorrectement. Assurez-vous que votre plist contient <SessionCreate> </true>.

Ne pas faire correspondre correctement le propriétaire du trousseau avec le processus de construction et s'assurer qu'une session de sécurité est créée entraînera toutes sortes de maux de tête. D'un point de vue diagnostique, vous pouvez introduire list-keychainset voir si le résultat correspond à vos attentes.

Ceci provient de la launchd.plistpage de manuel:

SessionCreate <boolean>

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

UserName <string>

Cette clé facultative spécifie l'utilisateur sous lequel exécuter le travail. Cette clé ne s'applique qu'aux services chargés dans le domaine système privilégié.

GroupName <string>

Cette clé facultative spécifie le groupe sous lequel exécuter le travail. Cette clé ne s'applique qu'aux services chargés dans le domaine système privilégié. Si UserName est défini et GroupName ne l'est pas, le groupe sera défini sur le groupe principal de l'utilisateur.

Enfin codeign

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

security find-identity -p codesigning -v

Concevoir un framework, dylib, etc.

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

Codesign de l'ensemble d'applications

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

Notes finales - si vous regardez comment Xcode le fait, ils ont configuré CODESIGN_ALLOCATEpour utiliser celui contenu dans Xcode, pas dans /usr/bin.

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

Le chemin de recherche est défini sur ${PLATFORM_PATH}:${TOOLCHAIN_PATH}:${PATH}, où PLATFORM path est le répertoire / usr / bin pour le SDK cible donné et TOOLCHAIN_PATH est le / usr / bin pour les outils hôtes Xcode.

Mettez vos clés dans le trousseau du système

C'est donc la commande qui fonctionne. -Aest d'empêcher Mac de demander le mot de passe. L'importation vers system.keychain ne nécessite pas d'interface graphique.

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

Mon trousseau était verrouillé. Il a résisté à mes avances pour changer ce fait ...

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

Déverrouiller le trousseau ne suffit pas. Vous devez également définir l'accès à la clé privée sur "Autoriser toutes les applications à accéder à cet élément". Et pour faire cela à partir de la ligne de commande, il faut réimporter la clé. Alors pour prendre les choses à la fois:

Déverrouillez le trousseau de connexion s'il est verrouillé. Il ne devrait pas être verrouillé cependant, mais de toute façon, voici comment procéder:

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

Si, pour une raison quelconque, votre machine de construction a le trousseau de connexion verrouillé et que vous ne souhaitez pas exposer ce mot de passe dans un script, vous devez utiliser un trousseau différent. Vous pouvez en créer un sur place et l'utiliser dans la commande précédente et 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

Importez ensuite vos certificats et les clés privées associées dans le trousseau de connexion à l'aide du 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 rendra votre clé privée définie sur "Autoriser toutes les applications à accéder à cet élément"

Donc, en utilisant tout cela, vous devriez être en mesure de créer un script qui installe le certificat requis pour créer une version ipa et la signer sans invite. Vous pouvez stocker le fichier .p12 dans votre référentiel, de sorte que toute machine puisse créer votre ipa sans nécessiter de configuration manuelle.

Outre le déverrouillage du trousseau (comme mentionné dans une autre réponse), vous devez autoriser l'accès de toutes les applications au jeton d'authentification Xcode dans le trousseau:

• Sélectionnez le trousseau "login"
• Sélectionnez la catégorie "Tous les éléments"
• Rechercher le mot clé "xcode"
• Sélectionnez «Autoriser toutes les applications à accéder à cet élément» pour tous les jetons Xcode
• N'oubliez pas d'ajouter l'étape de déverrouillage du trousseau (à partir des réponses précédentes)

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

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

J'ai donc essayé toutes les réponses ici et quelque chose n'allait pas tout à fait. Enfin, j'ai compris que lorsque j'ai redémarré mon service CI, il fonctionnait sous un utilisateur différent de celui auquel je m'attendais. Le passage à l'utilisateur qui avait réellement accès à la clé dans sa chaîne de connexion a tout résolu. Ce n'est peut-être pas un problème courant, mais je voulais documenter la raison spécifique de cette erreur, au cas où cela arriverait à d'autres.

Pour moi, rien de fonctionné ne semble devoir réinstaller Xcode une fois de plus. Jenkins continue de donner la même erreur. Vous gagneriez beaucoup de temps si vous déplacez simplement l'installation de Xcode dans la corbeille et la réinstallez. Assurez-vous d'exécuter la commande codesign à partir de la ligne de commande au moins une fois.

Même après si vous obtenez la même erreur, essayez de définir «Déverrouiller le trousseau?» propriété dans Jenkins et indiquez le chemin de votre login.keychain sous /Users/${USER}/Library/Keychains/login.keychain

J'espère que Dieu sera avec vous après ça.

Dans mon cas, cela a été causé par la création d'un trousseau avec un délai d'expiration par défaut de 300 s et une longue compilation xcode d'une durée de plus de 300 s. La solution de contournement, pour moi, était d'invoquer:

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

immédiatement après avoir créé le trousseau temporaire.

J'ai parcouru toutes ces suggestions et j'avais toujours des problèmes avec Fastlane gym dans un travail Jenkins. J'ai fait installer le certificat et déverrouillé le trousseau, et j'ai pu signer le code sur l'esclave lorsque j'ai exécuté manuellement la commande codesign sur la ligne de commande.

Pour contourner le problème, si Jenkins se connecte à l'esclave en utilisant JNLP au lieu de SSH, vous pourrez créer un code.

Pour moi, cela se produit lorsqu'un deuxième trousseau est ajouté manuellement et qu'il est verrouillé. Pour une raison quelconque, codesignessaie d'accéder au trousseau verrouillé et échoue même si les certificats sont dans le trousseau de connexion (et sont déverrouillés). Le déverrouillage du second résout le problème. Cela n'a pas de sens pour moi.

Après avoir essayé un certain nombre des solutions ci-dessus. J'ai réalisé qu'un facteur que j'avais, était que je commençais la construction en utilisant la console ION. Lorsque je suis revenu à la création de la version à partir de l'application Terminal, tout fonctionnait très bien.