"L'interaction de l'utilisateur n'est pas autorisée" lors de la signature d'une application OSX à l'aide du codesign.

Question

Notre construction automatisée est exécutée sur Jenkins. La construction elle-même est exécutée sur des esclaves, les esclaves é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 messages ici :

• En utilisant la sécurité déverrouiller-keychain immédiatement avant de signer pour déverrouiller le trousseau.
• Déplacer la clé de signature dans son propre trousseau.
• Déplacer la clé de signature dans le trousseau de connexion.
• Déplacer la clé de signature dans le trousseau du système.
• Paramétrage manuel de list-keychains à seulement le trousseau qui contient 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 du verrou est toujours présent. C'est le cas que je transmette le mot de passe sur la ligne de commande ou que je laisse le système 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", j'obtiens les résultats suivants faire voir la clé se verrouiller immédiatement après avoir exécuté la commande. Cela me fait penser qu'unlock-keychain ne fonctionne pas réellement. Je constate 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.

A partir de là, il semblerait que list-keychains soit ce qui ne fonctionne pas. Peut-être qu'aucun des deux ne fonctionne. :/

Hay un question similaire ici . La solution est intéressante - mettre "SessionCreate" à true dans launchctl. Mais je ne construis pas sur le maître - mon processus de construction est lancé par SSH sur une machine de construction esclave. Peut-être existe-t-il un moyen en ligne de commande pour faire ce que launchctl fait lorsque vous exécutez "SessionCreate" ?

Answer 1

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

Connectez-vous à votre utilisateur de construction via l'interface graphique et ouvrez Keychain Access. Sélectionnez votre clé privée de signature, faites un clic droit, choisissez Obtenir des informations, passez à l'onglet Contrôle d'accès et sélectionnez l'option "Autoriser toutes les applications à accéder à cet élément".

Answer 2

Eh bien, je suppose que je dois répondre à ma propre question aujourd'hui, parce qu'après deux jours et demi de travail acharné, une des choses que j'ai essayées semble avoir fonctionné. Je vais juste m'en éloigner maintenant et espérer que ça continue à marcher.

Essentiellement, il semble que cela se résume à -d system ne fonctionne pas 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"

Answer 3

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

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

En résumé, cela peut être provoqué par 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
 

Answer 4

Essayez d'appeler security unlock-keychain et codesign 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>