Certificados y keys faltantes en el llavero mientras usa Jenkins / Hudson como Integración continua para el desarrollo de iOS y Mac

Estoy tratando de mejorar Hudson CI para iOS y comenzar a Hudson tan pronto como el sistema comience. Para hacer esto estoy usando el siguiente script de launchd:

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

Esto funciona bien, pero cuando xcodebuild, que es iniciado por Hudson, intenta firmar una aplicación, falla porque no puede encontrar la key / certificate adecuada en el llavero. Sin embargo, el par key / certificate está ahí, ya que funciona correctamente si comienzo Hudson desde la línea de command.

¿Tienes alguna idea de por qué sucede?

Solutions Collecting From Web of "Certificados y keys faltantes en el llavero mientras usa Jenkins / Hudson como Integración continua para el desarrollo de iOS y Mac"

Después de pasar horas y días con este problema encontré una solución bastante fácil para esto. No importa si tiene un nombre de usuario distinto en su configuration de lanzamiento como se indicó anteriormente:

 <key>UserName</key> <string>user</string> 

Los certificates y keys faltantes deben estar en el llavero del sistema ( /Library/Keychains/System.keychain ). Encontré esto después de configurar un trabajo de Jenkins que ejecuta varias llamadas de shell de security . El que es interesante es security list-keychains : security list-keychains :

 + security list-keychains "/Library/Keychains/System.keychain" "/Library/Keychains/applepushserviced.keychain" "/Library/Keychains/System.keychain" 

Estos son los llaveros que Jenkins searchá en los certificates y las keys para que estén allí. Después de mover mis certs allí funciona. Asegúrese de copyr también el certificate »Autoridad de Certificación de relaciones con el desarrollador de Apple Worldwide« en el llavero del sistema; de lo contrario, verá un error de CSSMERR_TP_NOT_TRUSTED desde el codesign .

También es posible registrar más llaveros con security list-keychains -s [path to additional keychains] . No lo he probado, pero algo así como la security list-keychains -s $HOME/Library/Keychains/login.keychain como ejecución previa de shell en jenkins podría funcionar.

EDIT: He intentado agregar un llavero de usuario a la ruta de búsqueda con -s pero no pude conseguir que funcionara. Así que, por ahora, tenemos que copyr nuestros certificates y llaves en el llavero del sistema.

EDIT ^ 2: Lea y use la solución de Joensson en lugar de la mía, lo logró para acceder al llavero de los usuarios en lugar de solo al llavero del sistema.

Encontré una solución que me da acceso a los llaveros normales para mi usuario de Jenkins.

Además de especificar el elemento UserName en el plist como lo sugiere la respuesta aceptada, el truco para get acceso a los llaveros normales para el usuario que especificó en UserName es agregar también un elemento SessionCreate con un valor verdadero al file plist – / Library / LaunchDaemons / org.jenkins-ci.plist:

 <?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>EnvironmentVariables</key> <dict> <key>JENKINS_HOME</key> <string>/Users/Shanetworking/Jenkins/Home</string> </dict> <key>GroupName</key> <string>wheel</string> <key>KeepAlive</key> <true/> <key>Label</key> <string>org.jenkins-ci</string> <key>ProgramArguments</key> <array> <string>/bin/bash</string> <string>/Library/Application Support/Jenkins/jenkins-runner.sh</string> </array> <key>RunAtLoad</key> <true/> <key>UserName</key> <string>jenkins</string> <key>SessionCreate</key> <true /> </dict> 

A continuación, reinicie el daemon e intente ejecutar un trabajo en Jenkins que llame a los llaveros de la list de security, y ya no debería ver System.keychain como la única input sino el inicio de session normal y cualquier cadena de keys personalizada que pueda haber agregado a la list de llaveros para el usuario de "jenkins".

Ahora estoy usando códigos de certificates de un llavero personalizado en mi server de compilation Jenkins. No he instalado ningún certificate o key en mi llavero del sistema.

Tuvimos el mismo problema con un esclavo hudson iniciado como launchdaemon en Mac OSX Lion. Funcionó, cuando comenzamos el esclavo con webstart. La única diferencia que vimos fue una variable de entorno diferente.

 com.apple.java.jvmTask=WebStart 

funciona, si comenzamos el esclavo sin webstart, la variable era

 com.apple.java.jvmTask=CommandLine.java 

No encontramos ninguna manera de influir en el valor por adelantado. Sugiero que cree un nuevo nodo en Hudson, que se ejecute en la misma máquina y comience por webstart. Para iniciar el esclavo usamos la siguiente configuration de launchdaemon:

 <?xml version"1.0" encoding="UTF-8"?> <plist version="1.0"> <dict> <key>Label</key> <string>jenkins</string> <key>UserName</key> <string>apple</string> <key>Program</key> <string>/usr/bin/javaws</string> <key>ProgramArguments</key> <array> <string>-verbose</string> <string>-wait</string> <string>http://<hudson-hostname>:8080/computer/<node-name>/slave-agent.jnlp</string> </array> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <true/> <key>WorkingDirectory</key> <string>/Users/apple</string> </dict> </plist> 

Nos enfrentamos exactamente al mismo problema en Lion, así como en SnowLeopard. Tuvimos que comenzar un Tomcat / Hudson con xcodebuild trabajos como un service. Al comenzar desde la línea de command, xcodebuild podría acceder a login.keychain para usar el certificate que contiene. Pero después de reiniciar el cuadro, login.keychain no fue visible para xcodebuild y, por lo tanto, la firma falló.

Dado que necesitábamos proporcionar el certificate de nuestra empresa mediante un llavero, el llavero del sistema no era una opción. En su lugar, solucionamos el problema con una simple solución. Eliminamos el nombre de usuario, de modo que el daemon de inicio abra el process bajo raíz .

 <plist version="1.0"> <dict> <key>Label</key> <string>${LAUNCH_LABEL}</string> <key>Disabled</key> <false/> <key>RunAtLoad</key> <true/> <key>ProgramArguments</key> <array> <string>${INSTALL_DIR}/start.sh</string> </array> <key>StandardOutPath</key> <string>${INSTALL_DIR}/tomcat-stdout.log</string> <key>StandardErrorPath</key> <string>${INSTALL_DIR}/tomcat-stderr.log</string> </dict> </plist> 

El daemon de inicio llamó un script simple ( start.sh ), simula un inicio de session completo y ejecutó el progtwig deseado

 su -l username -c program 

Ahora, incluso después de arrancar, xcodebuild puede acceder a login.keychain. Esto también funciona en Snow Leopard, pero, si cierra el file de inicio de session específico del usuario en una session paralela (como el inicio / cierre de session de vnc), el llavero se pierde. El león se comporta diferente. Parece que Lion desacopla el llavero del usuario y lo asigna a una session de inicio de session.

Para mantener un llavero compartimentado para Jenkins / Hudson, moví el elemento launchctl de

 /Library/LaunchDaemons/org.jenkins-ci.plist 

a

 /Users/Shanetworking/Jenkins/Home/Library/LaunchAgents/org.jenkins-ci.plist 

Y eso me permite acceder al llavero privado creado para Jenkins.

Puedes probar mi Jenkins.app, https://github.com/stisti/jenkins-app , una forma alternativa de ejecutar a Jenkins. Ejecuta a Jenkins en la session del usuario, por lo que el acceso de Keychain no es un problema.

Tuve el mismo problema y traté de cambiar el nombre de usuario en /Library/LaunchDaemons/org.jenkins-ci.plist como se describe en una de las otras publicaciones. Sin embargo, todavía no funcionaba, y alguna NullPointerException oscura no me ayudó a identificar el problema. Por lo tanto, solo compartiría mi solución: también tuve que cambiar el propietario del directory JENKINS_HOME (definido también en org.jenkins-ci.plist):

 chown -R myBuildUser /Users/Shanetworking/Jenkins 

myBuildUser es el usuario que tiene los certificates instalados, y este es el usuario que especificé en el file Plist.

Esta solución fue bastante obvia cuando finalmente me di count, pero me tomó un par de horas para enterarme de esto, así que espero que esta publicación pueda ahorrarle time a otra persona 🙂

Agregando SessionCreate y configurando muchos certificates para "siempre confiar" en keychain manager trabajó para mí con buildbot comenzado desde plist … pero en algún momento, el inicio de códigos comenzó a fallar con CSSMERR_TP_NOT_TRUSTED. Me recuperé configurando el certificate de distribución de iPhone para 'usar los valores pnetworkingeterminados del sistema' en el administrador de llaveros. Incluso después de un reinicio, sin iniciar session, el esclavo de buildbot pudo firmar el código.