Manquant des certificats et des clés dans le trousseau d'accès lors de l'utilisation de Jenkins/Hudson Intégration Continue pour iOS et Mac développement
Je suis en train d'améliorer Hudson CI pour iOS et commencer à Hudson dès que le système démarre. Pour ce faire, je suis en utilisant la suite de launchd script:
<?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>Hudson CI</string>
<key>ProgramArguments</key>
<array>
<string>/usr/bin/java</string>
<string>-jar</string>
<string>/Users/user/Hudson/hudson.war</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>UserName</key>
<string>user</string>
</dict>
</plist>Cela fonctionne OK mais quand xcodebuild, qui est lancé par Hudson, essaie de se connecter à une application, il échoue parce qu'il ne trouve pas la bonne clé/certificat dans le trousseau d'accès. Toutefois clé/certificat de la paire qui est là depuis qu'elle travaille corriger si je commence à Hudson à partir de la ligne de commande.
Avez-vous une idée pourquoi ça arrive?
Vous devez vous connecter pour publier un commentaire.
Après avoir passé des heures et des jours avec ce problème je l'ai trouvé assez facile solution à cette question. Il n'a pas d'importance si vous avez un nom d'utilisateur distinct dans votre launchd de configuration comme indiqué ci-dessus:
Les certificats manquants et les clés sont sur le trousseau du système (
/Library/Keychains/System.keychain). J'ai trouvé cette après-je configurer un jenkins travail qui exécute plusieurssecurityshell appels. Celle qui est intéressant, c'estsecurity list-keychains:Qui sont les porte-clés jenkins va rechercher les certificats et les clés de sorte qu'ils devraient être là. Après, j'ai déménagé mon certs il fonctionne. Assurez-vous également de copier le »Apple Worldwide Developer Relations d'Autorité de Certification« certificat pour le système de porte-clés, sinon, vous verrez un
CSSMERR_TP_NOT_TRUSTEDerreur decodesign.Il est également possible d'enregistrer plus de porte-clés avec
security list-keychains -s [path to additional keychains]. Je n'ai pas essayé, mais quelque chose commesecurity list-keychains -s $HOME/Library/Keychains/login.keychaincomme un pré-construire l'exécution du shell dans jenkins pourrait fonctionner.EDIT: j'ai essayé d'ajouter un utilisateur d'un trousseau et le chemin de recherche avec
-smais je n'ai pas réussi à le faire fonctionner. Donc pour l'instant, nous avons à copier nos certificats et des clés dans le trousseau du système.MODIFIER^2: Lire et utiliser joensson' solution au lieu de la mienne, il a réussi à accéder aux keychain au lieu de simplement le trousseau du système.
sudocommande?security unlock -p password /path/to/System.keychainavec un mot de passe.J'ai trouvé une solution en me donnant accès à la régulière keychains pour mon Jenkins utilisateur.
En plus de spécifier le nom d'utilisateur de l'élément dans le fichier plist que l'on a accepté de répondre à l'indique, l'astuce pour obtenir l'accès à la normale de porte-clés pour l'utilisateur que vous avez spécifié dans le nom d'utilisateur est également ajouter un SessionCreate élément avec la valeur true pour le fichier plist - /Library/LaunchDaemons/org.jenkins-ci.plist :
Puis redémarrez le démon et essayez d'exécuter un travail de Jenkins, qui appelle liste de sécurité-porte-clés - et vous ne verrez plus le Système.trousseau comme seule entrée, mais la connexion classique et personnalisé porte-clés vous pourriez avoir ajouté à la liste des trousseaux pour les "jenkins" de l'utilisateur.
Je suis maintenant en utilisant codesigning certificats à partir d'un personnalisé keychain sur mon serveur de build Jenkins - je n'ai pas installé les certificats ou des clés dans mon trousseau du Système.
security default-keychain -s ~/Library/Keychains/codesign.keychainautrementsecurity find-identity ~/Library/Keychains/codesign.keychainserait montrer les identitésCSSMERR_TP_NOT_TRUSTED.Nous avons eu le même problème avec un hudson esclave qui a commencé comme un launchdaemon sur Mac OSX Lion. Il a travaillé, quand nous avons commencé l'esclave avec webstart. La seule différence que nous avons repéré est une autre variable d'environnement.
fonctionne, si nous avons commencé l'esclave sans webstart la variable a été
Nous n'avons trouvé aucun moyen d'influencer la valeur de l'avance. Je vous suggère de créer un nouveau nœud dans l'Hudson, en cours d'exécution sur la même machine et a commencé par webstart. Pour le démarrage de l'esclave nous utilisons les launchdaemon configuration:
Vous pouvez essayer mon Jenkins.app, https://github.com/stisti/jenkins-app, une autre façon d'exécuter Jenkins. Il fonctionne Jenkins dans la session de l'utilisateur, de sorte que le Trousseau d'accès n'est pas un problème.
J'ai connu le même problème, et j'ai essayé de changer le nom d'utilisateur /Library/LaunchDaemons/org.jenkins-ci.plist comme décrit dans l'un des autres postes. Cependant, il n'a toujours pas de travail, et quelque obscure NullPointerException ne m'aide pas à identifier le problème. Donc, je voudrais juste partager ma solution: j'ai dû également changer le propriétaire de l'jenkins_home comme pointant répertoire (défini dans org.jenkins-ci.plist en tant que bien):
myBuildUser est l'utilisateur qui possède les certificats installés, et c'est à l'utilisateur que j'ai spécifié dans le fichier plist.
Cette solution était tout à fait évident, quand j'ai enfin réalisé - mais il m'a fallu quelques heures pour savoir à ce sujet, alors j'espère que ce post peut gagner du temps pour quelqu'un d'autre 🙂
Nous avons été confrontés exactement le même problème sur Lion ainsi que sur SnowLeopard. Nous avons dû commencer un Tomcat/Hudson avec xcodebuild emplois en tant que service. Tout en commençant à partir de la ligne de commande, le xcodebuild pourrait accéder à la connexion.trousseau pour utiliser le certificat de contenus. Mais après redémarrage de la box, la connexion.trousseau n'était pas visible à xcodebuild et, par conséquent, la signature a échoué.
Depuis que nous avons besoin de fournir à nos certificat d'entreprise par un trousseau de clés, le trousseau du système n'était pas une option. Au lieu de cela, nous avons résolu le problème par une solution de contournement simple. Nous avons supprimé le nom de l'utilisateur, de sorte que le lancement démon lance le processus en vertu de racine.
Le lancement démon appelé un script simple (start.sh), la simulation complète de connexion et l'exécution du programme voulu
Maintenant, même après le démarrage, le xcodebuild pouvez accéder à la connexion.un trousseau de clés. Cela fonctionne sur Snow Leopard, mais, si vous fermez l'utilisateur de login spécifique.porte-clés dans une session parallèle (comme vnc connexion/déconnexion) le trousseau de clés perdu. Lion se comporte de façon différente. Semble que le Lion découple le trousseau de clés de l'utilisateur et lui attribue un identifiant de session.
De garder un compartimentée trousseau de clés pour Jenkins/Hudson, j'ai déplacé les launchctl élément de
à
Et qui me permet d'accéder au trousseau privé créé pour Jenkins.
L'ajout d'
SessionCreate
et le réglage de beaucoup de certificats de "toujours faire confiance" dans gestionnaire de trousseau
a fonctionné pour moi avec buildbot a commencé à partir de plist... mais à un certain point, codesign a commencé à défaut
avec CSSMERR_TP_NOT_TRUSTED. J'ai récupéré par la configuration de l'iPhone de Distribution cert "utiliser les paramètres système par défaut' dans le trousseau manager. Même après un redémarrage, sans vous connecter
le buildbot esclave était alors en mesure de signer du code, ouf.
L'ajout de ce depuis que j'ai eu le même problème, mais aucune de ces solutions n'a fonctionné pour moi.
Mon problème a été causé quand, après le certificat de signature est nécessaire pour être mis à jour, après qu'il avait expiré. Après la mise à jour, xcode et en cours d'exécution xcodebuild manuellement a bien fonctionné, MAIS Jenkins n'a pas pu signer l'application.
Voici comment je l'ai corrigé:
Regarder dans les Trousseau et de la recherche de la clé. Pour une raison que je ne comprends pas ce qui nous a donné des résultats différents.
Assurez-vous que la clé privée est dans le Système de niveau (si ce n'est pas le cas, alors faites-la glisser vers l'icône Système, sur la gauche.
Manuel de la Signature de Déplacer votre certificat de connexion au Système dans le trousseau d'accès. La connexion n'est pas accessible lors de l'archive et de générer de l'iap.