tools from for developer apple additional iphone xcode xcodebuild

iphone - from - xcode build ipa terminal



Ejecutando xcodebuild desde una terminal bifurcada (13)

Estoy intentando configurar un servidor de compilación automatizado para una aplicación de iPhone. Me gustaría poder tener compilaciones adhoc beta nocturnas para que los evaluadores puedan seguir el desarrollo.

He configurado xcode con éxito xcode para realizar compilaciones adhoc y también puedo iniciar la construcción desde la línea de comandos:

xcodebuild -configuration AdHoc -sdk iphoneos2.2 clean build

El problema que tengo es que la siguiente línea no funciona desde un terminal bifurcado (usando nohup o pantalla) y falla con la siguiente

Error de CodeSign: Identidad de firma de código ''Distribución de iPhone: XXXXX'' no coincide con ningún certificado de firma de código en su llavero. Una vez agregado al llavero, toque un archivo o limpie el proyecto para continuar.

Revisé las variables de entorno en mi shell, en nohup o en la pantalla y no encontré ninguna pista. Supongo que mi problema es que el terminal bifurcado no puede acceder al llavero, pero no tengo idea de cómo permitirlo.

Gracias por tu ayuda

¿Podría usar security list-keychains -s ${HOME}/Library/Keychains/login.keychain dentro del proceso de compilación para agregar explícitamente su llavero de inicio de sesión a la lista de búsqueda? Parece que desde la Terminal bifurcada, el proceso de compilación no muestra su llavero de usuario. Eso podría tener sentido si la lista de búsqueda de llaveros se basa en su sesión de seguridad actual: una sesión de terminal bifurcada dejaría la sesión de inicio de sesión como si ssh sobre la conexión de bucle invertido.

Miré el comando de seguridad y parece que los llaveros asignados a mi terminal no son los mismos cuando se bifurcan. Si lancé el comando de seguridad en la terminal, tengo:

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

mientras que al usar la pantalla tengo el siguiente resultado:

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

Dado que mis certificados de compilación están almacenados en el llavero de inicio de sesión, el error del signo de código parece normal.

¿Alguien sabe cómo podría asignar un llavero a una terminal? Lo he intentado sin éxito

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

¿Algunas ideas?

Tuve un error. La interacción del usuario no está permitida y se solucionó desbloqueando primero el llavero.

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

También traté de poner mis certs en el llavero del Sistema y estaba funcionando. Mi solución final fue poner todos mis certs relacionados con iPhone en un llavero dedicado llamado iPhone.keychain usando la aplicación Keychain Access

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

Si está ejecutando xcodebuild como root (que es cuando sudo), debe iniciar sesión como root y colocar sus certificados de firma en el llavero de root. A continuación, desbloquea el llavero con la seguridad que se muestra arriba.

Ok, el problema era dos cosas para mí, primero estaba desbloqueando el llavero;

security unlock-keychain login.keychain

La segunda fue una frase de contraseña (vacía)

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

ACTUALIZACIÓN: A tuvo un pequeño problema más tarde, cuando el script se desencadena desde un script web o sth. como eso. Simplemente ve /Library/Keychains/System.chain. Así que encontré una solución sucia (que puede conducir a problemas de seguridad, pero está bien para mí);

  • configure el inicio de sesión de pubkey ssh (desde el usuario que desea invocar el script de compilación, hasta el usuario real que tiene certificados y ejecutará xcodebuild) en mi caso, es el mismo usuario. Apache está trabajando como un someuser y todo para la compilación está configurado en someuser .

  • y mi script php (para desencadenar compilación) llamaba a ~ / build-script. Lo he cambiado así:

    ssh someuser @ localhost ~ / build-script

por lo que funciona en un tty real, y todo el llavero es accesible, todo funciona bien.

Yo si:

  • eliminar login.keychain de la lista

  • crear el propio llavero en $HOME/Library/Keychains/

  • agrégalo a la lista de llaveros (no especifiqué ningún dominio específico)

  • configurarlo como predeterminado

  • llame security unlock-keychain en él

  • agregar certificado de firma global (WWDRCA) a ella

  • importar clave privada y certificados de Desarrollo y Distribución a ella

Si hay login.keychain , sigo recibiendo el error "Interacción del usuario no permitido". ¡Así que eliminar login.keychain usando la security delete-keychain finalmente ayudó!

Otra solución :

  • Abra el acceso de llavero
  • Haga clic derecho en la clave privada
  • Seleccione "Obtener información"
  • Seleccione la pestaña "Control de acceso"
  • Haga clic en "Permitir que todas las aplicaciones accedan a este elemento"
  • Haga clic en "Guardar cambios"
  • Ingresa tu contraseña
  • Disfrutar

Desbloquear el llavero de inicio de sesión no funcionó para mí. Crear un llavero separado usando Keychain Access (llamado iOS) y luego agregar estos comandos a la compilación funcionó (al ejecutar Jenkins como mi propio usuario):

seguridad -v list-keychains -d sistema -s ~ / Library / Keychains / iOS.keychain; seguridad -v unlock-keychain -p contraseña ~ / Library / Keychains / iOS.keychain;

Sin embargo, esto parece más prometedor: https://wiki.jenkins-ci.org/display/JENKINS/Xcode+Plugin#XcodePlugin-Userinteractionisnlowlowed

Si está ejecutando security list-keychains y viendo que su llavero personalizado aparece EN ALGÚN LUGAR de la lista, pero aún así no funciona, podría ser que se encuentre con el problema que tuve al verificar los llaveros en orden desde la búsqueda. lista, y como no estaba desbloqueando login.keychain en mi sesión SSH, fallaría allí en lugar de pasar al siguiente llavero en la lista, que era el personalizado que quería desbloquear.

Establecer la lista de búsqueda en un llavero personalizado que desbloquee con el desbloqueo de security unlock-keychain funciona. Usar este método de la respuesta de Yann también eliminará tu login.keychain de la lista de búsqueda.

Para preservar login.keychain:

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

De esta manera, al usar la sesión de la GUI en la máquina, todavía tendrá acceso a los elementos de login.keychain , pero la firma del código revisará primero el llavero personalizado, que tendrá éxito si lo desbloqueó.

Como dice otro cartel,

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

Pero creo que solo tiene acceso al login.keychain cuando está conectado, en el contexto de la GUI (Acabo de probar en un sistema a través de SSH y pantalla, pero que también estoy conectado a través de VNC).

Aparentemente es posible usar launchctl para seleccionar el contexto de la GUI y ejecutar el programa, pero sospecho que solo funciona para el "usuario conectado" también.

Si prueba '' security show-keychain-info keychain-file '', obtendrá el siguiente error:

La interacción del usuario no está permitida

Y esa es una frase para buscar con más información. La otra solución es poner el certificado en tu llavero del sistema.

Hay dos (¡posiblemente tres!) Componentes para esto. Uno es que el llavero debe estar desbloqueado. En segundo lugar, hay una lista de control de acceso dentro del llavero que indica qué permisos se otorgan a las aplicaciones en el estado desbloqueado. Así que incluso si tiene el llavero desbloqueado con éxito, si la capacidad para acceder a la clave privada y firmar con ella no se le da a /usr/bin/codesign , aún recibirá este mensaje. Finalmente, si está en Mac OS Sierra, la ID de partición predeterminada asignada a las claves es incorrecta para que sea compatible con el codesign binario.

La solución es la siguiente:

1) Si tiene acceso a la GUI de Keychain Access, puede otorgar manualmente acceso a cada programa o / usr / bin / codesign haciendo clic derecho en su clave privada, seleccionando la pestaña "Control de acceso" y luego seleccionando "Permitir todas las aplicaciones" para acceder a este elemento "radio" o la lista de "Permitir siempre el acceso de estas aplicaciones".

2) Si encuentra este error, es probable que intente ejecutar codesign para un usuario que no inicie sesión. En este caso, claramente no tiene acceso a la GUI "Acceso a Llaveros". Para estos casos, verifica que falta la autorización de sign para la aplicación <null> , lo que aparentemente significa todas las aplicaciones, o específicamente /usr/bin/codesign usando:

security dump-keychain -i login.keychain

Sin embargo, no puede agregar o modificar atributos de control de acceso en modo interactivo por alguna razón, ¡solo eliminar! En realidad, tiene que eliminar manualmente la clave y volver a agregarla a la llave que especifica el indicador -T .

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

Donde -T especifica

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

3) Si está en Mac OS Sierra, modifique la ID de la partición para incluir la partición apple . Presumiblemente, este es el espacio de nombres asignado a codesign porque fue distribuido por Apple.

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

NOTA : La apple-tool de security inserta la partición apple-tool , por lo que el comando anterior preserva esa partición. Para obtener más información sobre este aspecto, consulte: http://www.openradar.me/28524119

Estoy usando Atlassian Bamboo 2.7 y OS X 10.7.3 Lion y he probado todos los enfoques encontrados en el hilo, pero todavía recibía el error de "interacción del usuario no permitido".

El problema era que, en una sesión de terminal remota (como "superusuario" como en el caso de Bamboo u otro sistema de compilación automatizado), el llavero que debe desbloquearse con los certificados de firma es diferente de lo que normalmente vería (tal como lo demostró Yann aquí ) cuando no eres superusuario.

Lo que finalmente funcionó para mí fue hacer lo siguiente:

  1. inicie sesión como administrador del sistema como se describe aquí
  2. crear el llavero de solo firma (por ejemplo, ios.keychain )
  3. agregarle los certificados de firma (junto con el certificado WWDRCA)

Verifíquelo yendo su y ejecutando security list-keychains en la terminal. Debería ver el ios.keychain entre la lista. ( sudo security list-keychains no mostrará lo mismo):

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

Descubrí que todavía tiene que agregar ios.keychain al alcance de su búsqueda antes de ejecutar el comando de unlock-keychain . En su script de compilación, ejecute las siguientes líneas:

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

actualización para las personas que tienen problemas similares con Jenkins:

Si configura su Mac para ejecutar jenkins a través de LaunchDaemons, debe asegurarse de agregar

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

Entonces todo el ci.plist se vería así:

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

He estado atrapado con el mismo problema que muchas personas tienen. Específicamente experimenté el problema cuando se ejecuta desde un script de shell de Jenkins obtuve el mismo error de ** interacción del usuario no está permitido **. Al ejecutar desde un shell ssh, mi script funcionó bien.

La diferencia que la mayoría de la gente también ha visto es que si ejecuta security-keychain obtendrá:

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

Pero cuando se ejecuta en el shell ssh, obtengo:

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

Y la mayoría de las personas tendrán todas sus claves / certificados, etc. en el llavero de la cuenta de usuario. Al igual que algunas personas sugirieron que es fácil crear un nuevo llavero que sea distinto del llavero del usuario, y volver a buscarlo para el material de firma de XCode. Terminé poniendo el mío aquí: /Library/Keychains/sysiphone.keychain

Creo que el problema es que para mi configuración (y posiblemente para la tuya también), te estás ejecutando en un dominio de preferencia de seguridad diferente (sistema vs. usuario). Finalmente, así es como obtuve mi sysiphone.keychain para que aparezca:

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

... y mágicamente las cosas comenzaron a desarrollarse en Jenkins. Guau ... eso fue alrededor de 4 horas por el desagüe para mí. Suspiro.