"L'interaction de l'utilisateur n'est pas autorisée" en essayant de signer une application OSX à l'aide de codesign


145

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"?


Comment définir le mot de passe du trousseau sur circleci?
Sachin Kumaram

@SachinKumaram semble être une nouvelle question viable?
Trejkaz

Réponses:


205

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».

onglet de contrôle d'accès


2
De rien. Vous pouvez également envisager d'ajouter le code d'accès à la liste des applications en bas au lieu d'autoriser toutes les applications comme je l'ai fait. C'est déjà là dans ma capture d'écran, mais je pense qu'à l'origine ce n'était pas le cas.
bmauter le

3
J'ai dû afficher le répertoire / usr avec apple.stackexchange.com/a/34872/6052 pour pouvoir ajouter codesignà la liste "Toujours autoriser".
Heath Borders

24
juste une note qu'en plus de cela, vous devez faire tout le reste security unlock-keychainaussi
cwd

13
En outre, vous souhaiterez peut-être déplacer vos clés de la connexion au système afin qu'elles soient accessibles lorsque vous effectuez des builds à distance sur votre machine.
Krystian

8
Quelqu'un connaît-il un moyen de le faire à partir de la ligne de commande? Ma machine de construction distante ne me permettra pas de faire cela sur le partage d'écran pour des raisons de sécurité .
devios1

78

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"

17
Merci. J'ai pu préciser cela. Exécutez simplement la commande suivante juste avant d'essayer de construire: security -v unlock-keychain -p "$ KEYCHAIN_PASSWORD" "$ HOME / Library / Keychains / login.keychain"
pir800

3
Il n'y a donc aucun moyen d'accéder codesignvia ssh sans stocker le mot de passe de connexion dans un script?
chakrit

2
@chakrit dans l'exemple ci-dessus, je ne transmets que le mot de passe du trousseau, pas le mot de passe de connexion. Je me rends compte que pour beaucoup d'utilisateurs, le trousseau de connexion est le seul trousseau, mais dans notre cas, nous conservons les clés de signature dans un keystore séparé pour les rendre plus faciles à synchroniser pour construire des machines. Mais oui, beaucoup de ces choses semblent plutôt gênantes pour les builds automatisés, ce qui m'amène à me demander si Apple fait même des builds automatisés.
Trejkaz

@Trejkaz oh d'accord, au moins partager un mot de passe de trousseau n'est pas aussi mauvais.
chakrit

Dans mon cas d'utilisation de builds à distance automatisés, stocker le mot de passe du trousseau dans un .envfichier n'est pas si grave, car le .envfichier contient déjà des clés sensibles, par exemple. AWS et Heroku. Dans notre cas, les informations d'identification du signe de code liées à la construction sont stockées dans un trousseau nouvellement créé qui est ensuite supprimé après la construction. Ensuite, il est recréé à nouveau pour la prochaine version. Cependant, le logintrousseau doit encore être ouvert, tout security unlock-keychain -p pass login.keychaincomme le lien manquant ici. Merci!
Petrus Repo

19

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

2
Sur El Capitan, vous pouvez également le faire via l'interface utilisateur. Ouvrez simplement l'application du trousseau, faites un clic droit sur votre trousseau (connexion, système, etc.) et cliquez sur quelque chose qui correspond le mieux à `` modifier les paramètres pour <your_keychain> ''.
rubybeginner

Cela rétablit toujours mon accès au trousseau système, Confirmmême après avoir modifié l'accès. : /
Alex Zavatone

Cela m'a été utile !!
Nori

J'ai du mal avec ça depuis 2 jours, avant de trouver ton commentaire, merci !!!
Gilad Novik le

16

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>

4
C'est la même chose que de le faire sur deux lignes. Je suppose que la différence est que si la première commande échoue, elle n'exécutera pas la seconde.
Trejkaz le

1
Pour moi, ce ne sont pas les mêmes. Je les appelle via ant sshexecet à chaque fois cela crée une nouvelle session ssh.
ZhekaKozlov

2
Vous pouvez également faire plus d'une ligne à travers une seule session ssh, si vous le souhaitez vraiment. Donc ... c'est toujours pareil, mis à part le traitement des erreurs.
Trejkaz le

13

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.


3
Mec tu peux définitivement écrire un article à ce sujet, je le cherchais depuis 2 jours. Je ne sais pas combien de trucs et de messages stackoverflow j'ai lu. Un grand merci à vous!
Damien

Merci pour cette procédure pas à pas utile!
Taras Nikulin

ACL sur le trousseau était la partie manquante pour moi. merci pour l'explication claire monsieur!
Keuha le

11

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


Mais il demande toujours le nom d'utilisateur et le mot de passe
Durai Amuthan.H

Comment mettre les clés dans le trousseau du système ....... copier-coller du travail d'accès au trousseau?
Ashish Karpe

Glisser-déposer @AshishKarpe
Alistra

Le glisser-déposer a-t-il toujours obtenu la même erreur: === BUILD TARGET PatientPortal OF PROJECT PatientPortal WITH CONFIGURATION Debug === Vérifier les dépendances Aucun profil pour 'com.abc.xyz360' n'a été trouvé: Xcode n'a pas trouvé de profil d'approvisionnement correspondant à 'com .abc.xyz360 ». La signature de code est requise pour le type de produit 'Application' dans le SDK 'iOS 10.2'
Ashish Karpe

Il indique que vous n'avez pas de profil de provisionnement installé sur la machine, pas qu'il vous manque les clés @AshishKarpe
Alistra

5

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


3

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

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


2

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.


2

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)

Capture d'écran


1

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

1

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.


J'ai eu exactement le même problème. Merci pour votre réponse. :)
Paweł K

0

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.


0

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.


0

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.


0

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.


-1

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.