web-dev-qa-db-fra.com

Exécuter xcodebuild depuis un terminal forké

J'essaie de configurer un serveur de construction automatisé pour une application iPhone. J'aimerais pouvoir avoir des versions bêta adhoc nocturnes afin que les testeurs puissent suivre le développement.

J'ai installé xcode avec succès xcode pour effectuer des builds adhoc et je peux également lancer la build à partir de la ligne de commande:

xcodebuild -configuration AdHoc -sdk iphoneos2.2 clean build

Le problème que je rencontre est que la ligne suivante ne fonctionne pas à partir d'un terminal bifurqué (en utilisant Nohup ou screen) et a échoué avec ce qui suit

Erreur CodeSign: l'identité de signature de code "Distribution iPhone: XXXXX" ne correspond à aucun certificat de signature de code dans votre trousseau. Une fois ajouté au trousseau, touchez un fichier ou nettoyez le projet pour continuer.

J'ai vérifié mes variables d'environnement dans mon shell et dans Nohup ou écran et je n'ai trouvé aucun indice. Je suppose que mon problème est que le terminal forké ne peut pas accéder au trousseau mais je n'ai aucune idée de la façon de le permettre.

Merci de votre aide

iphonexcodexcodebuild
58
Yann Biancheri

J'ai eu une erreur l'interaction de l'utilisateur n'est pas autorisée et je l'ai résolu en déverrouillant d'abord le trousseau

security unlock-keychain /Users/yannooo/Library/Keychains/login.keychain

J'ai également essayé de mettre mes certificats dans le trousseau du système et cela fonctionnait. Ma dernière solution a été de mettre tous mes certificats liés à l'iPhone dans un trousseau dédié nommé iPhone.keychain en utilisant l'application Keychain Access 

security list-keychains -s /Users/yannooo/Library/Keychains/iPhone.keychain 
security unlock-keychain -p keychainpassword /Users/yannooo/Library/Keychains/iPhone.keychain
91
Yann Biancheri

Il y a deux (peut-être trois!) Composants à cela. L'un est le trousseau doit être déverrouillé. Deuxièmement, il y a une liste de contrôle d'accès à l'intérieur du trousseau qui indique quelles autorisations sont accordées aux applications à l'état déverrouillé. Donc, même si le trousseau est déverrouillé avec succès, si la possibilité d'accéder à la clé privée et de signer avec elle n'est pas donnée à /usr/bin/codesign, Vous obtiendrez toujours ce message. Enfin, si vous êtes sous Mac OS Sierra, l'ID de partition par défaut attribué aux clés est incorrect afin d'être compatible avec le binaire codesign.

La solution est la suivante:

1) Si vous avez accès à l'interface graphique d'accès au trousseau, vous pouvez accorder manuellement l'accès à chaque programme ou/usr/bin/codesign en cliquant avec le bouton droit sur votre clé privée, en sélectionnant l'onglet "Contrôle d'accès" puis en sélectionnant "Autoriser toutes les applications" pour accéder à cet élément "radio ou à la liste" Toujours autoriser l'accès par ces applications ".

2) Si vous rencontrez cette erreur, vous essayez probablement d'exécuter codesign pour un utilisateur non connecté. Dans ce cas, vous n'avez clairement pas accès à l'interface graphique "Accès au trousseau". Pour ces cas, vous vérifiez l'autorisation sign manquante pour l'application <null>, Ce qui signifie apparemment toutes les applications, ou spécifiquement /usr/bin/codesign En utilisant:

security dump-keychain -i login.keychain

Cependant, vous ne pouvez pas ajouter ou modifier les attributs de contrôle d'accès en mode interactif pour une raison quelconque - supprimez uniquement! Vous devez en fait supprimer manuellement la clé et l'ajouter à nouveau au trousseau en spécifiant l'indicateur -T.

security import login.keychain -P "<password>" -T /usr/bin/codesign

Où -T Spécifie

-T  Specify an application which may access the imported key (multiple -T options are allowed)

3) Si vous êtes sous Mac OS Sierra, modifiez l'ID de partition pour inclure la partition Apple. Vraisemblablement, c'est l'espace de noms attribué à codesign car il a été distribué par Apple.

security set-key-partition-list -S Apple-tool:,Apple: -k "<password>" login.keychain

[~ # ~] note [~ # ~] : La partition Apple-tool est insérée par l'outil security, la commande ci-dessus conserve donc cette partition. Pour plus d'informations sur cet aspect, voir: http://www.openradar.me/28524119

29
markshiz

Une autre solution :

  • Ouvrez l'accès au trousseau
  • Clic droit sur la clé privée
  • Sélectionnez "Obtenir des informations"
  • Sélectionnez l'onglet "Contrôle d'accès"
  • Cliquez sur "Autoriser toutes les applications à accéder à cet élément"
  • Cliquez sur "Enregistrer les modifications"
  • Tapez votre mot de passe
  • Prendre plaisir
11
Michaël Witrant

Pourriez-vous utiliser security list-keychains -s ${HOME}/Library/Keychains/login.keychain à l'intérieur du processus de construction pour ajouter explicitement votre trousseau de connexion à la liste de recherche? Il semble que depuis le terminal forké, le processus de construction ne voit pas votre trousseau utilisateur. Cela pourrait avoir un sens si la liste de recherche de trousseau est basée sur votre session de sécurité actuelle - une session de terminal fourchue quitterait la session de connexion comme si vous ssh via la connexion de bouclage.

9
user23743

mise à jour pour les personnes rencontrant des problèmes similaires avec Jenkins:

Si vous configurez votre Mac pour lancer jenkins via LaunchDaemons, vous devez vous assurer d'ajouter

<key>SessionCreate</key>
<true />

Ainsi, l'ensemble ci.plist ressemblerait à ceci:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.Apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>Label</key>
 <string>Jenkins</string>
 <key>UserName</key>
 <string>user</string>
 <key>GroupName</key>
 <string>staff</string>
 <key>ProgramArguments</key>
 <array>
 <string>/usr/bin/Java</string>
 <string>-Xmx512m</string>
 <string>-jar</string>
 <string>/path/to/jenkins/jenkins.war</string>
 </array>
 <key>RunAtLoad</key>
 <true/>
 <key>KeepAlive</key>
 <true/>
 <key>EnvironmentVariables</key>
   <dict>
     <key>JENKINS_HOME</key>
     <string>/path/to/jenkins/home</string>
   </dict>
 <key>SessionCreate</key>
 <true />
</dict>
</plist>

J'ai été coincé avec le même problème que beaucoup de gens ci-dessus. Plus précisément, j'ai rencontré le problème lors de l'exécution à partir d'un script Jenkins Shell, j'ai eu la même erreur ** L'interaction utilisateur n'est pas autorisée **. Lors de l'exécution à partir d'un shell ssh, mon script a bien fonctionné.

La différence que la plupart des gens ont également constatée est que si vous exécutez security list-keychain vous obtiendrez:

$ security list-keychain
  "/Library/Keychains/System.keychain"
  "/Library/Keychains/System.keychain"

Mais lors de l'exécution dans le shell ssh, j'obtiendrais:

$ security list-keychain
    "/Users/<i>user_account_name</i>/Library/Keychains/login.keychain"
    "/Library/Keychains/System.keychain"

Et la plupart des gens auront toutes leurs clés/certificats, etc. dans le trousseau du compte utilisateur. Comme certains l'ont suggéré, il est facile de créer un nouveau trousseau de clés distinct du trousseau de clés utilisateur et de le revendre pour votre signature XCode. J'ai fini par mettre le mien ici: /Library/Keychains/sysiphone.keychain

Je pense que le problème est que pour ma configuration (et peut-être aussi pour la vôtre), vous exécutez dans un domaine de préférence de sécurité différent (système vs utilisateur). Enfin - voici comment j'ai fait apparaître mon sysiphone.keychain:

$ Sudo security list-keychains -d system -s "/Library/Keychains/sysiphone.keychain"
Password: *****
$ security list-keychains -d system
    "/Library/Keychains/sysiphone.keychain"

... et par magie, les choses ont commencé à se construire à Jenkins. Wow ... c'était environ 4 heures dans les égouts pour moi. Soupir.

6
Bernt Habermeier

Ok, le problème était deux choses pour moi, la première était de déverrouiller le trousseau;

security unlock-keychain login.keychain

La deuxième phrase était (vide),

security import blahblahbackup.p12 -k login.keychain -T /usr/bin/codesign -P ""

MISE À JOUR: A a eu un petit problème plus tard, lorsque le script est déclenché à partir d'un script Web ou de qch. comme ça. Il voit juste /Library/Keychains/System.chain. J'ai donc trouvé une solution de contournement sale (ce qui peut entraîner des problèmes de sécurité mais ok pour moi);

  • configurer la connexion pubkey ssh (de l'utilisateur qui veut appeler le script de construction, à l'utilisateur réel qui a des certificats et exécutera xcodebuild) dans mon cas, c'est le même utilisateur. Apache fonctionne comme someuser et tout pour la construction est configuré sur someuser.

  • et mon script php (pour déclencher la construction) appelait ~/build-script. J'ai changé ça comme ça:

    ssh someuser @ localhost ~/build-script

donc ça marche dans un vrai tty, et tout le trousseau est accessible, tout fonctionne bien.

6
Furkan Mustafa

Comme le dit une autre affiche,

security list-keychains -s  "~/Library/Keychains/login.keychain"

Mais je pense que vous n'avez accès au login.keychain que lorsque vous êtes connecté, dans le contexte de l'interface graphique (je viens de tester sur un système via SSH et screen, mais auquel je suis également connecté via VNC).

Il est apparemment possible d'utiliser launchctl pour sélectionner le contexte GUI et exécuter le programme, mais je soupçonne que cela ne fonctionne que pour "l'utilisateur connecté".

Si tu essayes 'security show-keychain-info keychain-file ', vous obtiendrez l'erreur suivante:

L'interaction de l'utilisateur n'est pas autorisée

Et c'est une phrase avec laquelle rechercher pour plus d'informations. L'autre solution est de mettre le certificat dans votre trousseau système!

4
jrg

J'ai regardé la commande de sécurité et il semble que les trousseaux attribués à mon terminal ne sont pas les mêmes lorsqu'ils sont bifurqués. Si j'ai lancé la commande de sécurité dans le terminal, j'ai:

$ security list-keychains
  "/Users/yannooo/Library/Keychains/login.keychain"
  "/Library/Keychains/System.keychain"

alors qu'en utilisant écran j'ai la sortie suivante:

$ security list-keychains
    "/Library/Keychains/System.keychain"
    "/Library/Keychains/System.keychain"

Puisque mes certificats de build sont stockés dans le trousseau de connexion, l'erreur de signe de code que j'ai semble normale.

Est-ce que quelqu'un sait comment attribuer un trousseau à un terminal? J'ai essayé ça sans succès

security login-keychain -s /Users/yannooo/Library/Keychains/login.keychain

Des idées?

2
Yann Biancheri

J'utilise Atlassian Bamboo 2.7 et OS X 10.7.3 Lion et j'ai essayé toutes les approches trouvées dans le fil, mais j'obtenais toujours l'erreur "interaction utilisateur non autorisée".

Le problème était que, dans une session de terminal distant (en tant que "superutilisateur" comme dans le cas de Bamboo ou d'un autre système de construction automatisé), le trousseau à déverrouiller contenant les certificats de signature est différent de ce que vous verriez normalement (tel comme l'a montré Yann dans ici ) quand vous n'êtes pas superutilisateur.

Ce qui a finalement fonctionné pour moi a été de faire ce qui suit:

  1. connectez-vous en tant qu'administrateur système comme décrit ici
  2. créer le trousseau de signature uniquement (par exemple, ios.keychain)
  3. ajoutez-y les certificats de signature (avec le certificat WWDRCA)

Vérifiez-le en accédant à su et en exécutant security list-keychains sur le terminal. Vous devriez voir le ios.keychain parmi la liste. (Sudo security list-keychains ne montrera pas la même chose):

sh-3.2# security list-keychains
"/private/var/root/Library/Keychains/login.keychain"
"/Library/Keychains/ios.keychain"
"/Library/Keychains/System.keychain"

J'ai constaté que vous devez encore ajouter ios.keychain à votre champ de recherche avant de faire le unlock-keychain commande. Dans votre script de génération, exécutez les lignes suivantes:

KEYCHAIN=/Library/Keychains/ios.keychain
# the -s option adds $KEYCHAIN to the search scope, while the -d option adds $KEYCHAIN to the system domain; both are needed
security -v list-keychains -d system -s $KEYCHAIN 
security -v unlock-keychain -p bambooiphone $KEYCHAIN
2
Aldrich Co

Le déverrouillage du trousseau de connexion n'a pas fonctionné pour moi. La création d'un trousseau distinct à l'aide de Keychain Access (appelé iOS), puis l'ajout de ces commandes à la build a fonctionné (lors de l'exécution de Jenkins en tant que mon propre utilisateur):

sécurité -v list-keychains -d system -s ~/Library/Keychains/iOS.keychain; security -v unlock-keychain -p password ~ ​​/ Library/Keychains/iOS.keychain;

Cela semble plus prometteur, cependant: https://wiki.jenkins-ci.org/display/JENKINS/Xcode+Plugin#XcodePlugin-Userinteractionisnotallowed

2
Kyle Robson

Si vous exécutez security list-keychains et en voyant votre trousseau personnalisé apparaître QUELQUE PART dans la liste mais cela ne fonctionne toujours pas, il se peut que vous rencontriez le problème que j'ai eu par lequel les trousseaux sont vérifiés dans l'ordre à partir de la liste de recherche, et puisque je n'étais pas ' t déverrouillage login.keychain dans ma session SSH, il échouerait plutôt que de passer au trousseau suivant dans la liste, qui était celui que je voulais déverrouiller.

Définition de la liste de recherche sur un trousseau personnalisé que vous déverrouillez avec security unlock-keychain travaux. L'utilisation de cette méthode dans la réponse de Yann supprimera également votre login.keychain de la liste de recherche.

Pour conserver login.keychain:

security list-keychains -s ~/Library/Keychains/custom.keychain ~/Library/Keychains/login.keychain

De cette façon, lorsque vous utilisez la session GUI sur la machine, vous aurez toujours accès à login.keychain éléments, mais la signature de code vérifiera d'abord le trousseau personnalisé, qui réussit si vous l'avez déverrouillé.

2
darvids0n

Si vous exécutez xcodebuild en tant que root (ce que vous êtes lorsque vous Sudo), vous devez vous connecter en tant que root et mettre vos certificats de signature dans le trousseau de root. Déverrouillez ensuite le trousseau avec la sécurité comme ci-dessus.

1
cdespinosa

J'ai fait:

  • supprimer login.keychain de la liste

  • créer son propre trousseau dans $HOME/Library/Keychains/

  • l'ajouter à la liste des trousseaux (je n'ai spécifié aucun domaine spécifique)

  • définissez-le par défaut

  • appel security unlock-keychain dessus

  • ajouter un certificat de signature globale (WWDRCA)

  • y importer la clé privée et les certificats de développement et de distribution

S'il y a login.keychain, J'obtiens toujours l'erreur "Interaction utilisateur non autorisée". Supprimant ainsi login.keychain en utilisant security delete-keychain enfin aidé!

0
lef