"L'interaction de l'utilisateur n'est pas autorisée" en essayant de signer une application OSX à l'aide de codesign
Notre version automatisée fonctionne sur Jenkins. La construction elle-même fonctionne sur des esclaves, ces derniers étant exécutés via SSH.
Je reçois 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 publications ici:
- Utiliser la clé 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 système.
- Définissez manuellement les trousseaux de liste uniquement sur le trousseau contenant la clé.
Dans tous les cas, je reçois 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 constaté qu'il ne déverrouillait pas le trousseau. Si je regarde dans Keychain Access, le symbole de verrou est toujours présent. C'est le cas si je passe le mot de passe sur la ligne de commande ou si je le laisse le demander. Déverrouiller le même trousseau à l'aide de l'interface graphique me demandera le mot de passe, puis le déverrouille. De plus, si j'exécute "security lock-keychain", je do vois le verrou à clé immédiatement après l'exécution de la commande. Cela me fait penser que unlock-keychain ne fonctionne pas réellement. J'éprouve 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 cela, il semblerait que list-keychains ne fonctionne pas. Peut-être que ni travail. : /
Il y a un question similaire ici . La solution est intéressante - définissez "SessionCreate" sur true dans launchctl. Mais je ne construis pas sur le maître - mon processus de construction est démarré à partir de SSH sur une machine de construction esclave. Peut-être existe-t-il un moyen en ligne de commande de faire ce que launchctl fait lorsque vous exécutez "SessionCreate"?
Eh bien, je suppose que je peux répondre à ma propre question aujourd'hui, car après l'avoir poignardée pendant deux jours et demi, l'une des choses que j'ai essayée semble avoir fonctionné. Je vais simplement m'éloigner de ça maintenant et j'espère que ça continuera à fonctionner.
Essentiellement, il semble que -d system ne fonctionne pas réellement. Donc, beaucoup de réponses aux 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"
Moi aussi je me suis battu contre ça. Rien ne m'a aidé jusqu'à ce que j'ai essayé la suggestion sur http://devnet.jetbrains.com/thread/311971 . Merci ashish agrawal!
Connectez-vous à votre utilisateur 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 Lire les informations, passez à l'onglet Contrôle d'accès et sélectionnez "Autoriser toutes les applications à accéder à cet élément".
Aucune des autres réponses n'a fonctionné pour moi.
Ce qui m'a finalement sauvé était ce post
En résumé, cela peut être dû à un délai d’attente par défaut de 5 minutes, ce 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-keychain et codesign en tant 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>
Placez vos clés dans le trousseau Système
Donc, c'est la commande qui fonctionne. -A est d'empêcher Mac de demander un mot de passe. L'importation dans system.keychain ne nécessite pas d'interface graphique.
Sudo security import <cert.p12> -k "/Library/Keychains/System.keychain" -P <passphrase> -A
Utilisation de la sécurité pour créer un trousseau pour/usr/bin/codesign
Importer le certificat et le faire fonctionner par programmation avec codesign n’est pas une question d’utilisation de la connexion ou de trousseaux système, ni de prier un dieu de la codesign. Vous devez juste avoir le bon jeu d'autorisations. Je recommande de créer un nouveau trousseau spécialement à des fins de codesign.
Pour que codesign ne produise pas une errSecInternalComponent, vous devez obtenir une liste de partitions (ACL) correcte. Je vais marcher à travers les marches:
Créer le trousseau
security create-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"
à ce stade, le trousseau est déverrouillé mais n'apparaîtra pas dans 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 à partir de list-keychains, vous n'aurez plus login.keychain dans votre liste de recherche.
Déverrouiller 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 valeurs par défaut du trousseau
security set-keychain-settings "${TESTING_KEYCHAIN}"
En ne spécifiant aucun argument, le délai de verrouillage automatique sera illimité et le verrouillage automatique sera suspendu.
Importez vos certificats de signature à partir d'un fichier .p12
security import "${DIST_CER}" -P "${CERTIFICATE_PASSWORD}" -k "${KEYCHAIN_NAME}" -T /usr/bin/codesign
Importez les certificats et donnez l'accès codesign à l'aide de l'option -T.
Définir la liste de contrôle d'accès sur le trousseau
security set-key-partition-list -S Apple-tool:,Apple: -s -k "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"
C'est une exigence qui manque à beaucoup de gens. Vous pouvez voir ce que macOS fait en utilisant dump-keychain. Ce qui dans le cas de la codification nécessite Apple: et Apple-tool:. -s fait référence à la signature de certificats.
Gitlab-Runner, Jenkins et autres
Une chose très importante pour tout système de coureur ou de build de type CI est de s’assurer que le processus est démarré correctement à partir de launchd. 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. En termes de diagnostic, vous pouvez introduire list-keychains et voir si le résultat correspond à vos attentes.
Cela provient de la page de manuel launchd.plist:
SessionCreate <boolean>
Cette clé spécifie que le travail doit être créé dans une nouvelle sécurité La session d'audit plutôt que la session par défaut pour le contexte est appartient à. Voir auditon (2) pour plus de détails.
UserName <string>
Cette clé facultative spécifie l'utilisateur sur lequel exécuter le travail. Cette clé est seulement applicable aux services chargés dans le système privilégié domaine.
GroupName <string>
Cette clé facultative spécifie le groupe dans lequel exécuter le travail. Cette clé est seulement applicable aux services chargés dans le système privilégié domaine. Si UserName est défini et que GroupName ne l’est pas, le groupe sera alors défini sur le groupe principal de l'utilisateur.
Enfin codesign
Vous pouvez rechercher le hachage des certificats de signature à l'aide de find-identity
security find-identity -p codesigning -v
Coder un framework, un dylib, etc.
/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" "$SIGNABLE"
Codez le paquet d'applications
/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" --entitlements entitlements.xcent "$SIGNABLE"
Notes finales - si vous regardez comment Xcode le fait, il définit 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 sur ${PLATFORM_PATH}:${TOOLCHAIN_PATH}:${PATH}, où chemin PLATEFORME est le répertoire/usr/bin pour le SDK cible donné et TOOLCHAIN_PATH est le répertoire/usr/bin pour les outils hôte Xcode.
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 de la clé privée sur "Autoriser toutes les applications à accéder à cet élément". Et faire cela en ligne de commande nécessite de réimporter la clé. Donc, pour prendre les choses à la fois:
Déverrouillez le trousseau de connexion s'il est verrouillé. Cela ne devrait cependant pas être verrouillé, 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, le trousseau de connexion est verrouillé sur votre machine de génération et que vous ne souhaitez pas exposer ce mot de passe dans un script, vous devez utiliser un autre trousseau. 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
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 fera que votre clé privée soit définie sur "Autoriser toutes les applications à accéder à cet élément".
Donc, en utilisant tous ces éléments, vous devriez pouvoir créer un script qui installe le certificat requis pour créer un ipa de version et le 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.
J'ai donc essayé chaque réponse ici et quelque chose n'allait pas. Enfin, j'ai découvert que lorsque j'ai redémarré mon service CI, il fonctionnait sous un utilisateur différent de celui auquel je m'attendais. Changer pour l'utilisateur qui avait réellement accès à la clé dans sa chaîne de connexion a tout corrigé. 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.
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
Pour moi, cela se produit lorsqu'un deuxième trousseau est ajouté manuellement et qu'il est verrouillé. Pour une raison quelconque, codesign tente d'accéder au trousseau verrouillé et échoue même si les certificats se trouvent dans le trousseau de connexion (et sont déverrouillés). Déverrouiller le second résout le problème. Cela n'a aucun sens pour moi.
Dans mon cas, cela était dû à la création d’un trousseau avec un délai d’expiration par défaut de 300 secondes et une longue compilation xcode de plus de 300 secondes. La solution de contournement, pour moi, consistait à invoquer:
security set-keychain-settings -t <longer timeout in seconds> <keychain>
immédiatement après la création du trousseau temporaire.
Pour moi, rien ne fonctionne semble avoir à réinstaller Xcode à nouveau. Jenkins continue à donner la même erreur . Vous gagneriez beaucoup de temps si vous déplacez simplement l'installation de Xcode vers la Corbeille et réinstallez-le. 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é au sein de Jenkins et donnez le chemin à votre login.keychain sous /Users/${USER}/Library/Keychains/login.keychain
J'espère que dieu soit avec vous après ça.
J'ai parcouru toutes ces suggestions et je rencontrais toujours des problèmes pour utiliser la variable gym de fastlane dans un travail de Jenkins. J'avais le certificat installé et le trousseau déverrouillé, et j'étais capable de coder sur l'esclave lorsque j'ai exécuté manuellement la commande codesign sur la ligne de commande.
En guise de solution de contournement, si Jenkins se connecte à l'esclave en utilisant JNLP au lieu de SSH, vous serez en mesure de coder.
Outre le déverrouillage du trousseau (comme indiqué 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 articles"
- Recherche du 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)
