2011-12-16 9 views
10

Estoy intentando encender un cierto llavero, y cerrar otro. Necesito esto porque nuestra empresa & appstore identidades se llaman igual.CLI: Cambie los llaveros para firmar un xcodebuild

Ahora, hago un "llavero de desbloqueo de seguridad" seguido de un "llavero de seguridad predeterminado" para abrir el llavero correcto y hacer un "llavero de seguridad" en el llavero que deseo no usar.

Pero xcodebuild aún ve las entradas en ambos llaveros y se da por vencido.

iPhone Distribution: Company name.: ambiguous (matches "iPhone Distribution: Company name." in /Users/user/Library/Keychains/login.keychain and "iPhone Distribution: Company name" in /Users/user/Library/Keychains/enterprise.keychain) 

¿Cómo evito que el sistema encuentre la entrada en el llavero que bloqueo?

Respuesta

3

Solución: He puesto todas las cosas relacionadas con la tienda de aplicaciones en el llavero de inicio de sesión, y las cosas de la empresa en un archivo separado de llavero.

En el buildscript, alterno entre los de la siguiente manera:

# 1. Only activate the System and either the Appstore(=login) or Enterprise keychain. 
security list-keychains -s $KEYCHAIN_NAME $SYSTEM_KEYCHAIN 

# 2. Loop through App Schema's 
for APP_SCHEME in ${APP_SCHEMES[@]}; do 
    echo "--= Processing $APP_SCHEME =--" 
    xcodebuild -scheme "${APP_SCHEME}" archive 
done ### Looping through App Schema's 

# 3. Restore login & system keychains 
security list-keychains -s $APPSTORE_KEYCHAIN $ENTERPRISE_KEYCHAIN $SYSTEM_KEYCHAIN 
+0

Sin embargo, esta es una opción potencialmente no deseada en caso de construcciones paralelas, cuando las tareas pueden cambiar el llavero incorrecto al mismo tiempo. Todavía preferiría la opción del script PackageApplication para establecer el llavero preferido para la búsqueda de certificados. – lef

0

Otra solución para la versión de Xcode y 6 a continuación: especificar su certificado SHA1 en lugar de por su nombre (ambigua). De "hombre codesign":

If identity consists of exactly forty hexadecimal digits, it is instead 
interpreted as the SHA-1 hash of the certificate part of the desired iden- 
tity. In this case, the identity's subject name is not considered. 

Y de "seguridad ayudan a encontrar-certificado"

-Z Print SHA-1 hash of the certificate 

Por desgracia, este método requiere el uso de la secuencia de comandos PackageSign, que ha sido deprecated in Xcode 7

+0

Suena prometedor ... Pero no veo cómo puedo especificar un SHA1 en xcode. Probablemente tendría que hacer la firma por un guión. De todos modos, gracias por la pista. Voy a profundizar en esto para ver si puede ayudarnos. – P5ycH0

+1

@ P5ych0 Lo siento, no he visto esto hasta ahora. Sí, hacemos el script de inicio de sesión, por ejemplo, con "xcrun -sdk iphoneApplication --sign --embed " –

+0

Pero como puedo ver en el script PackageApplication, hay fragmentos que verifican el parámetro --sign para coincida con "Distribución de iPhone", así que supongo que usar SHA-1 no es factible a menos que este script con errores esté pirateado. – lef

9

le puede decir Xcode qué llavero usar:

xcodebuild "OTHER_CODE_SIGN_FLAGS=--keychain '$PATH_TO_KEYCHAIN'" 

O, si llamas codesign directamente:

codesign --keychain "$PATH_TO_KEYCHAIN" 

Si utiliza PackageApplication, no hay una manera de fijar esto. Sin embargo, PackageApplication es un script bastante simple que se puede volver a implementar si es necesario (muy útil si se está integrando con un sistema/script más grande).

+0

Suena genial. Voy a intentarlo. ¿Deben cargarse los llaveros especificados en la aplicación de llavero, o es suficiente su presencia en el sistema de archivos? – P5ycH0

+0

No creo que el llavero deba agregarse a la aplicación de llavero, pero no estoy seguro. –

Cuestiones relacionadas