L'exécution de xcodebuild à partir d'un fork terminal

Question

Je suis en train de configurer un système automatisé de serveur pour une application iPhone. Je aimerais être en mesure d'avoir tous les soirs adhoc versions bêta de sorte que les testeurs peuvent suivre le développement.

J'ai programmés xcode avec succès xcode pour effectuer adhoc construit et je peux aussi lancer la construction de la ligne de commande:

xcodebuild -configuration AdHoc -sdk iphoneos2.2 construction propre

Le problème que je vais avoir, c'est que la ligne suivante ne fonctionne pas à partir d'un fork terminal (à l'aide de nohup ou de l'écran) et a échoué avec l'

CodeSign erreur: Signature du Code d'Identité d'iPhone de Distribution: XXXXX " ne correspond à aucun certificat de signature de code dans votre trousseau de clés. Une fois ajouté dans le trousseau d'accès, de toucher à un fichier ou à nettoyer de poursuivre le projet.

J'ai vérifié mes variables d'environnement dans ma coquille et en nohup ou de l'écran et n'a pas trouvé un indice. Je suppose que mon problème est que la fourche terminal ne peut pas accéder au trousseau mais je n'ai aucune idée sur la façon de les autoriser.

Merci pour votre aide

Answer 1

J'ai dû te erreur interaction de l'Utilisateur n'est pas autorisé et résolu par le déverrouillage du trousseau de la première

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

J'ai aussi essayé de mettre ma certs dans le Système du trousseau et cela fonctionnait. Ma dernière solution a été de mettre tous mon iPhone liées certs dans une trousseau nom iPhone.keychain en utilisant le Trousseau d'Accès de l'application

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

Answer 2

Il y a deux composantes à ce. L'un est le trousseau de clés doit être déverrouillé, mais il y a aussi une liste de contrôle d'accès à l'intérieur du trousseau qui raconte les autorisations sont données pour les applications, même dans l'état déverrouillé. Même si vous avez le trousseau de clés avec succès déverrouillé, si la capacité à accéder à la clé privée et de signer avec il n'est pas donné à /usr/bin/codesign ensuite, vous obtiendrez toujours ce message. La solution est comme suit:

1) Si vous avez accès au Trousseau d'Accès GUI, alors vous pouvez accorder manuellement chaque programme /usr/bin/codesign accéder par un clic droit sur votre clé privée, en sélectionnant l'onglet "Access Control", puis en sélectionnant l'option "Autoriser toutes les applications pour accéder à cet élément" de la radio ou de la liste de "Toujours autoriser l'accès de ces applications" à la liste.

2) Si vous rencontrez cette erreur, les chances sont que vous essayez d'exécuter codesign , pour un non-utilisateur de connexion. Dans ce cas, il est clair que vous n'avez pas accès à la "Trousseau d'Accès" de l'interface graphique. Pour ces cas, vous vérifiez l' sign autorisation manquante pour l'application <null>, ce qui signifie apparemment toutes les applications, ou plus précisément /usr/bin/codesign en utilisant:

security dump-keychain -i login.keychain

Cependant, vous ne pouvez pas ajouter ou modifier l'accès des attributs de contrôle en mode interactif pour une raison --seulement supprimer! Vous devez supprimer manuellement la clé et re-ajouter au trousseau de la spécification de l' -T drapeau.

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)

Answer 3

Une autre solution :

• Ouvrez le Trousseau d'Accès
• Clic droit sur la clé privée
• Sélectionnez "Obtenir Des Informations"
• Sélectionnez l'onglet "Access Control"
• Cliquez sur "Autoriser toutes les applications pour accéder à cet élément"
• Cliquez Sur "Enregistrer Les Modifications"
• Entrez votre mot de passe
• Profitez de

Answer 4

Ok, le problème c'est deux choses pour moi, la 1ère a été déverrouiller le trousseau de clés;

security unlock-keychain login.keychain

La deuxième a été (vide) mot de passe,

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

Mise à JOUR: Un eu un petit problème plus tard, lorsque le script est déclenchée à partir d'un script web ou qqch. comme ça. Il voit juste /Bibliothèque/Keychains/Système.de la chaîne. J'ai donc trouvé un sale solution de contournement (ce qui peut conduire à des problèmes de sécurité, mais ok pour moi);

• le programme d'installation pubkey une connexion ssh (à partir de l'utilisateur qui veut appeler le script de construction effective d'un utilisateur qui a le certificat et exécuter xcodebuild) dans mon cas, c'est même utilisateur. Apache fonctionne comme someuser et tout pour construire la configuration, sur someuser.

• et mon script php (pour le déclenchement de construire) appelait ~/build-script. J'ai changé, comme ceci:

  ssh someuser@localhost ~/build-script

de sorte qu'il fonctionne dans un véritable ats, et tous les keychain est accessible, tout fonctionne bien.