Jenkins - Xcode build works codesign échoue

Question

Ci-dessous, mon script de construction (n'utilise pas le plugin xcodebuild).

L'étape de construction fonctionne
J'ai créé un trousseau séparé avec les certificats et les clés privées requis, et ils sont visibles dans Accès au trousseau.
Les commandes de trousseau n'échouent pas dans le script
security list-keychains les montre comme des porte-clés valides

Il s’agit comme si la commande de déverrouillage ne réussissait pas vraiment. Lorsque je tente d’exécuter des codesign depuis la ligne de commande via

codesign -f -s "iPhone Developer: mycert" -v sample.app/ --keychain /Users/Shared/Jenkins/Library/Keychains/JenkinsCI.keychain

Je reçois

CSSM_SignData returned: 000186AD sample.app/: unknown error -2070=fffffffffffff7ea

bien que je ne sois pas sûr d’émuler correctement depuis la ligne de commande car vous pouvez au mieux

Sudo -u jenkins bash xcodebuild ONLY_ACTIVE_Arch="NO" CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED="NO" -scheme "MySchemeName" CONFIGURATION_BUILD_DIR="`pwd`" security list-keychains -s /Users/Shared/Jenkins/Library/Keychains/JenkinsCI.keychain + security default-keychain -d user -s /Users/Shared/Jenkins/Library/Keychains/JenkinsCI.keychain + security unlock-keychain -p jenkins /Users/Shared/Jenkins/Library/Keychains/JenkinsCI.keychain + security list-keychains "/Users/Shared/Jenkins/Library/Keychains/JenkinsCI.keychain" "/Library/Keychains/System.keychain" + security default-keychain "/Users/Shared/Jenkins/Library/Keychains/JenkinsCI.keychain" + codesign -f -s '$IDENTITY_GOES_HERE.' -v sample.app/ sample.app/: User interaction is not allowed.

Toute aide est grandement appréciée.

Jamieson · Accepted Answer

Nous n'utilisons pas Jenkins mais nous l'avons déjà vu dans notre automatisation de génération. Voici comment nous l'avons résolu:

1) Créez votre trousseau de construction. Ceci contiendra la clé privée/le certificat utilisé pour la signature de code:

security create-keychain -p [keychain_password] MyKeychain.keychain

Le keychain_password est à vous. Vous l'utiliserez plus tard pour déverrouiller le trousseau lors de la construction.

2) Importez la clé privée (* .p12) pour votre identité CodeSign:

security import MyPrivateKey.p12 -t agg -k MyKeychain.keychain -P [p12_Password] -A

La clé ici est le drapeau "-A". Cela permettra l'accès au trousseau sans avertissement. C'est pourquoi vous voyez l'erreur "L'interaction de l'utilisateur n'est pas autorisée". Si vous tentiez cette construction via l'interface utilisateur Xcode, il vous inciterait à "Autoriser l'accès" à votre trousseau.

3) Quelle que soit l’enregistrement du trousseau (par exemple, en l’enregistrant dans le contrôle de code source), assurez-vous qu’il est inscriptible et exécutable par votre utilisateur de build.

Lorsque vous êtes prêt à compiler, ajoutez les éléments suivants avant d'exécuter xcodebuild:

# Switch keychain security list-keychains -s "/path/to/MyKeyhain.keychain" security default-keychain -s "/path/to/MyKeychain.keychain" security unlock-keychain -p "[keychain_password]" "/path/to/MyKeychain.keychain"

Si vous exécutez localement, vous voudrez peut-être ajouter quelque chose à la fin de votre script de construction qui repassera au trousseau de connexion (~/Library/Keychains/login.keychain), par exemple

# Switch back to login keychain security list-keychains -s "~/Library/Keychains/login.keychain" security default-keychain -s "~/Library/Keychains/login.keychain"

Essayez ça. Nous créons un trousseau distinct pour chaque identité que nous utilisons (notre propre base et des constructions pour le compte de clients). Dans le cas de notre société, nous avons à la fois un compte AppStore et un compte d'entreprise. Cela peut entraîner des conflits de noms lors de la création de codes (par exemple: les deux comptes sont résolus en "Distribution iPhone: ACME Corporation"). En conservant ces identités dans des trousseaux distincts, nous évitons ce conflit.

mckeejm · Answer

Déplacer les certificats vers le trousseau système et le référencer a résolu le problème

user2317738 · Answer

Requis pour déverrouiller le trousseau avant de signer "Security unlock-keychain -p"

Stephen Quan · Answer

Dans cette réponse, nous ajoutons/supprimons votre certificat iOS sans manipuler le trousseau de connexion ni changer le trousseau par défaut en:

Utilisez un trousseau temporaire
Ajouter un trousseau temporaire à la liste de recherche (sans le remplacer)
Déverrouiller le trousseau temporaire sans délai
Importez votre certificat en utilisant -T /usr/bin/codesign
Faire la construction
Supprimer le certificat en supprimant le trousseau temporaire

Crée un trousseau temporaire. J'ai ajouté le $$ qui est le PID. Cela signifie que nous permettons de paralléliser le script en permettant la création simultanée de plusieurs trousseaux de clés temporaires:

# Create temp keychain MY_KEYCHAIN="MyKeychain-$$.keychain" MY_KEYCHAIN_PASSWORD="secret" security create-keychain -p "$MY_KEYCHAIN_PASSWORD" "$MY_KEYCHAIN"

Ajoute un trousseau temporaire à la liste de recherche. Veillez à utiliser security list-keychains -s pour ajouter votre trousseau, sinon vous construirez des builds exécutés dans un autre thread:

# Append keychain to the search list security list-keychains -d user -s "$MY_KEYCHAIN" $(security list-keychains -d user | sed s/\"//g) security list-keychains

Déverrouille le trousseau temporaire sans délai d'expiration du verrouillage (security set-keychain-settings). Si vous oubliez de corriger le délai de relocalisation, les générations prenant plus longtemps que le délai de relocalisation par défaut déclenchent l'invite du mot de passe:

# Unlock the keychain security set-keychain-settings "$MY_KEYCHAIN" security unlock-keychain -p "$MY_KEYCHAIN_PASSWORD" "$MY_KEYCHAIN"

Importer un certificat iOS et accorde un accès /usr/bin/codesign sans exiger de mot de passe Invite.

# Import certificate security import $CERT -k "$MY_KEYCHAIN" -P "$CERT_PASSWORD" -T "/usr/bin/codesign"

Étant donné que nous utilisons un trousseau temporaire et que nous savons qu'il ne contient qu'un seul certificat, nous pouvons, par programme, dériver IOS_IDENTITY (requis en tant qu'entrée pour les étapes de génération).

# Detect the iOS identity IOS_IDENTITY=$(security find-identity -v -p codesigning "$MY_KEYCHAIN" | head -1 | grep '"' | sed -e 's/[^"]*"//' -e 's/".*//') IOS_UUID=$(security find-identity -v -p codesigning "$MY_KEYCHAIN" | head -1 | grep '"' | awk '{print $2}') # New requirement for MacOS 10.12 security set-key-partition-list -S Apple-tool:,Apple: -s -k $MY_KEYCHAIN_PASSWORD $MY_KEYCHAIN

Faites votre construction maintenant

# Insert your custom build steps

Supprimer le trousseau temporaire. Remarque, ce faisant, apparaîtra automatiquement dans la liste de recherche. c'est-à-dire que tous les autres trousseaux resteront.

# Delete the temp keychain security list-keychains security delete-keychain "$MY_KEYCHAIN" security list-keychains

raed · Answer

Une seule chose a résolu ce problème pour moi.

Ce que j'ai fait est de définir la clé privée de le certificat de signature dans le trousseau. Accès à Autoriser toutes les applications à accéder à cet élément.

Graham Perks · Answer

J'ai copié tous les certificats/clés privées dans un nouveau trousseau (vous pouvez cliquer avec le bouton droit de la souris sur les éléments et simplement copier-coller). Dans le nouveau trousseau, cliquez avec le bouton droit de la souris sur chaque clé privée, Obtenir des informations -> Contrôle d'accès et mettez les clés à la disposition de toutes les applications.

Surtout, dans la partie supérieure gauche de l'application Trousseau se trouve la liste des trousseaux. Remettez-les en ordre pour que le nouveau trousseau apparaisse en premier dans la liste.

Une autre réponse que j’ai trouvée donnait l’étape de construction pour déverrouiller ce trousseau pendant la construction:

KEYCHAIN=/Users/<you>/Library/Keychains/codesign.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 <keychain password> $KEYCHAIN

Aaron · Answer

FWIW ... laissez-moi jeter une autre raison possible pour cela. Il est possible que des certificats en double flottent et que codesign ne sache pas lequel utiliser. Lorsque vous exécutez cette commande à partir de votre esclave Jenkins, voyez-vous des certificats valides en double? Quelque chose comme ça:

$ security find-identity -v -p codesigning 1) AAAAE00066DED2FE77DF43012573AD5B6188AAAA "iPhone Developer: JOHN SMITH (XAAAAFSUSJ)" 2) AAAAE00066DED2FE77DF43012573AD5B6188AAAA "iPhone Developer: JOHN SMITH (XAAAAFSUSJ)" 3) BBBB5B03DB566209964247982908D3DD74D1BBBB "iPhone Distribution: Example, Inc. (TBBBBH5HUE)" 4) BBBB5B03DB566209964247982908D3DD74D1BBBB "iPhone Distribution: Example, Inc. (TBBBBH5HUE)" 5) BBBB5B03DB566209964247982908D3DD74D1BBBB "iPhone Distribution: Example, Inc. (TBBBBH5HUE)" 6) AAAAE00066DED2FE77DF43012573AD5B6188AAAA "iPhone Developer: JOHN SMITH (XAAAAFSUSJ)" 7) AAAAE00066DED2FE77DF43012573AD5B6188AAAA "iPhone Developer: JOHN SMITH (XAAAAFSUSJ)" 8) BBBB5B03DB566209964247982908D3DD74D1BBBB "iPhone Distribution: Example, Inc. (TBBBBH5HUE)" 8 valid identities found

Si tel est le cas, j’ai jugé utile de procéder comme suit et de revenir à un ensemble de certificats de signature de base:

Supprimez tous les certificats sur l'esclave Jenkins (et les autres esclaves Jenkins qui exécuteront votre script de génération).
Suivant: vérifiez que vous avez 0 identifies en exécutant $ security find-identity -v -p codesigning à nouveau.
Dans le référentiel de votre application, incluez un MyApp.keychain personnalisé contenant les deux certificats valides. Assurez-vous de supprimer tous les doublons.
Désormais, à partir de votre script de génération et avant le processus codesign, il est exécuté à partir de déverrouillé MyApp.keychain et définissez-le par défaut. Cela expose ces certificats comme disponibles pour codesign.
Enfin, vérifiez à nouveau sur votre esclave Jenkins: $ security find-identity -v -p codesigning que vous voyez seulement les certificats que vous avez regroupés dans MyApp.keychain et qu'il n'y a pas d'autres identités de signature sur le système. Si vous voyez toujours des doublons après cela, vous avez d'autres endroits où votre esclave Jenkins est informé de ces certificats.

Asaf Shveki · Answer

Il s'agit d'une erreur de signature de code. La commande xcodebuild ne peut pas accéder à la clé privée de votre certificat, car il fonctionne via l'esclave de Jenkins avec SSH.

Exécutez cette ligne dans votre script Shell avant d’exécuter xcodebuild afin d’autoriser l’accès:

security set-key-partition-list -S Apple-tool:,Apple: -s -k <ROOT-PASSWORD> /Users/<YOUR USER NAME>/Library/Keychains/login.keychain-db

J'espère que cela pourra aider!

yonix · Answer

Cela peut également être causé par un délai d'attente par défaut sur le trousseau.

Découvrez ma réponse à "L'interaction de l'utilisateur n'est pas autorisée" en essayant de signer une application OSX à l'aide de codesign

CrazyJoeLv · Answer

Voici ce qui a fonctionné pour moi:

J'ai créé un nouveau trousseau et copié toutes les entrées de "login", nommé "jenkins_ios"
Fait nouveau trousseau par défaut.
Ajout d'une nouvelle étape "Execute Shell" dans la configuration Jenkins, ce devrait être la première étape avant la signature de code, contenant les éléments suivants:

KEYCHAIN=/Users/<user>/Library/Keychains/jenkins_ios.keychain security -v list-keychains -s $KEYCHAIN security -v unlock-keychain -p <password> $KEYCHAIN security set-keychain-settings -t 3600 -l $KEYCHAIN

La dernière étape est vraiment importante, car le délai de déverrouillage par défaut peut ne pas être assez long pour que votre projet soit construit correctement (c'est exactement ce qui s'est passé avec notre projet, car il est énorme et que l'étape de construction prenait environ 5 à 7 minutes et que le trousseau était verrouillé pour le moment. il était nécessaire pour codesign).

magnusarinell · Answer

J'ai supprimé les clés en double des chaînes de clés (login et système) et tout a commencé à fonctionner Comme je n'avais qu'un certificat mais plusieurs clés, j'ai dû filtrer les clés pour les voir correctement.