ios - llavero - ver contraseña de correo en iphone

Faltan certificados y claves en el llavero mientras se usa Jenkins/Hudson como integración continua para el desarrollo de iOS y Mac

Question

Intento mejorar Hudson CI para iOS e iniciar Hudson tan pronto como el sistema se inicie. Para hacer esto, uso 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 clave / certificado adecuado en el llavero. Sin embargo, el par clave / certificado está allí ya que funciona correctamente si inicio Hudson desde la línea de comandos.

¿Tienes alguna idea de por qué sucede?

Answer 1

Agregar SessionCreate y establecer muchos certificados para ''always trust'' en keychain manager funcionó para mí con buildbot started from plist ... pero en algún momento, codesign comenzó a fallar con CSSMERR_TP_NOT_TRUSTED. Me recuperé configurando el certificado de distribución de iPhone para ''usar los valores predeterminados del sistema'' en el administrador de llavero. Incluso después de reiniciar, sin iniciar sesión, el esclavo buildbot pudo firmar el código, por favor.

Answer 2

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 configuración de launchd como se indicó anteriormente:

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

Los certificados y claves faltantes deben estar en el llavero del sistema ( /Library/Keychains/System.keychain ). Lo encontré después de configurar un trabajo de jenkins que ejecuta varias llamadas al shell de security . El que es interesante es security list-keychains :

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

Esos son los llaveros que jenkins buscará en los certificados y claves para que estén allí. Después de mover mis certificados allí funciona. Asegúrese de copiar también el certificado »Autoridad de certificación de relaciones con desarrolladores de Apple Worldwide« en el llavero del sistema, de lo contrario, verá un error CSSMERR_TP_NOT_TRUSTED de codesign .

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

EDITAR: He intentado agregar un llavero de usuario a la ruta de búsqueda con -s pero no pude hacerlo funcionar. Así que por ahora, tenemos que copiar nuestros certificados y claves en el llavero del sistema.

EDITAR ^ 2: Leer y usar la solution Joensson en lugar de la mía, logró acceder al llavero de los usuarios en lugar de simplemente al llavero del sistema.

Answer 3

Enfrenté el mismo problema e intenté 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, simplemente compartiría mi solución: también tuve que cambiar el propietario del directorio JENKINS_HOME (definido en org.jenkins-ci.plist también):

chown -R myBuildUser /Users/Shared/Jenkins

myBuildUser es el usuario que tiene los certificados instalados, y este es el usuario que especifiqué en el archivo plist.

Esta solución fue bastante obvia cuando finalmente me di cuenta, pero me llevó un par de horas averiguarlo, así que espero que esta publicación pueda ahorrarle tiempo a otra persona :-)

Answer 4

He encontrado una solución que me da acceso a los llaveros regulares para mi usuario de Jenkins.

Además de especificar el elemento UserName en el plist como lo sugiere la respuesta aceptada, el truco para acceder a los keychains normales para el usuario que especificó en UserName es agregar también un elemento SessionCreate con un valor verdadero para el archivo 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/Shared/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>

Luego, reinicie el daemon e intente ejecutar un trabajo en Jenkins que llame a los list-keychains de seguridad, y ya no debería ver System.keychain como la única entrada, sino el inicio de sesión normal y cualquier cadena personalizada que haya agregado a la lista de llaveros para el usuario "jenkins".

Ahora estoy usando certificados de asignación de nombres de un llavero personalizado en mi servidor de compilación de Jenkins. No he instalado ningún certificado o clave en mi llavero del sistema.

Answer 5

Nos enfrentamos exactamente al mismo problema en Lion y en SnowLeopard. Tuvimos que iniciar Tomcat / Hudson con trabajos de xcodebuild como un servicio. Al comenzar desde la línea de comando, xcodebuild podría acceder a login.keychain para usar el certificado que contiene. Pero después del reinicio de la caja, login.keychain no estaba visible para xcodebuild y, por lo tanto, la firma falló.

Como necesitábamos proporcionar el certificado de nuestra empresa por medio de un llavero, el llavero del sistema no era una opción. En cambio, solucionamos el problema mediante una solución simple. Eliminamos el nombre de usuario para que el demonio de lanzamiento inicie el proceso en la 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 lanzamiento llamado script simple ( start.sh ), simulación, inicio de sesión completo y ejecución del programa deseado

su -l username -c program

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

Answer 6

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

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

a

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

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

Answer 7

Podrías probar mi Jenkins.app, https://github.com/stisti/jenkins-app , una forma alternativa de ejecutar Jenkins. Se ejecuta Jenkins en la sesión de usuario, por lo que el acceso de llavero no es un problema.

Answer 8

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 detectamos 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 forma de influir en el valor por adelantado. Sugiero que cree un nuevo nodo en Hudson, que se ejecute en la misma máquina y se inicie mediante webstart. Para iniciar el esclavo usamos la siguiente configuración 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>