La nostra build automatizzata è in esecuzione su Jenkins. La build stessa è in esecuzione su slave, con gli slave eseguiti tramite SSH.

Ottengo un errore:

00:03:25.113 [codesign-app] build/App.app: User interaction is not allowed.

Ho provato tutti i suggerimenti che ho visto finora in altri post qui:

• Utilizzo del portachiavi di sblocco di sicurezza immediatamente prima della firma per sbloccare il portachiavi.
• Spostare la chiave di accesso nel proprio portachiavi.
• Spostamento della chiave di firma nel portachiavi di accesso.
• Spostamento della chiave di firma nel portachiavi di sistema.
• Impostazione manuale dei portachiavi dell'elenco solo sul portachiavi che contiene la chiave.

In tutti i casi, ottengo lo stesso errore.

Nel tentativo di diagnosticare il problema, ho provato a eseguire il comando "security unlock-keychain" sul mio terminale locale e ho scoperto che in realtà non sblocca il portachiavi - se guardo in Keychain Access, il simbolo del lucchetto è ancora lì. Questo è il caso se passo la password dalla riga di comando o se lascio che me lo richieda. Sbloccare lo stesso portachiavi utilizzando la GUI mi chiederà la password e quindi lo sbloccerà. Inoltre, se corro "sicurezza lock-portachiavi", io faccio vedere il blocco tasti immediatamente dopo l'esecuzione del comando. Questo mi fa pensare che il keychain di sblocco non funzioni davvero. Provo lo stesso comportamento su Lion (che stiamo usando per gli schiavi build) e Mavericks (su cui sto sviluppando.)

Successivamente, ho provato ad aggiungere -v a tutti i comandi di sicurezza:

list-keychains "-d" "system" "-s" "/Users/tester/.secret/App.keychain"
Listing keychains to see if it was added: ((
        "/Library/Keychains/System.keychain"
))
unlock-keychain "-p" "**PASSWORD**" "/Users/tester/.secret/App.keychain"
build/App.app: User interaction is not allowed.

Da ciò, sembrerebbe che i portachiavi dell'elenco siano ciò che non funziona. Forse nessuno dei due funziona. : /

C'è una domanda simile qui . La soluzione è interessante: imposta "SessionCreate" su true in launchctl. Ma non sto costruendo sul master - il mio processo di compilazione viene avviato da SSH su una macchina di compilazione slave. Forse c'è un modo da riga di comando per fare ciò che launchctl sta facendo quando si esegue "SessionCreate"?

Anch'io ho combattuto questo. Nulla ha aiutato fino a quando ho provato il suggerimento su http://devnet.jetbrains.com/thread/311971 . Grazie ashish agrawal!

Accedi al tuo utente di build tramite la GUI e apri Accesso Portachiavi. Seleziona la tua chiave privata di firma, fai clic con il pulsante destro del mouse, scegli Ottieni informazioni, passa alla scheda Controllo accessi e seleziona "Consenti a tutte le applicazioni di accedere a questo elemento".

Bene, immagino di riuscire a rispondere alla mia domanda oggi, perché dopo averlo pugnalato per due giorni e mezzo, una delle cose che ho provato sembra aver funzionato. Ho intenzione di ritirarmi da questo ora e spero che continui a funzionare.

In sostanza, sembra che non funzioni -d systemdavvero. Quindi molte risposte ad altre domande qui dovrebbero probabilmente essere aggiornate per riflettere questo.

security -v list-keychains -s "$KEYCHAIN" "$HOME/Library/Keychains/login.keychain"
security list-keychains # so we can verify that it was added if it fails again
security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN"
codesign --sign "$SIGNER_IDENTITY" --force --signature-size 9600 \
         --resource-rules src/AppResourceRules.plist --timestamp --verbose \
         "$APP"

Nessuna delle altre risposte ha funzionato per me.

Ciò che alla fine mi ha salvato è stato questo post

Per riassumere, questo può essere causato da un timeout predefinito di 5 minuti, che attiverà questo errore dopo un lungo build.

Aggiustare:

security set-keychain-settings -t 3600 -l ~/Library/Keychains/login.keychain

Prova a chiamare security unlock-keychaine codesigncome comando a una riga. Questo mi ha aiutato. Qualcosa di simile a:

security unlock-keychain -p <password> /Users/<user>/Library/Keychains/login.keychain && codesign --force --verify --verbose --sign "<certificate id>" <app name>

Utilizzo di Sicurezza per creare un portachiavi per / usr / bin / codesign

Importare il certificato e farlo funzionare a livello di codice in modo programmatico non è una questione di utilizzo del login o dei portachiavi di sistema o della preghiera a qualche dio del codice. Devi solo avere le autorizzazioni corrette impostate. Consiglio di creare un nuovo portachiavi appositamente per scopi di design dei codici.

In questi giorni per arrivare codesigna non produrre errSecInternalComponentè necessario ottenere l'elenco di partizioni (ACL) corretto. Camminerò attraverso i passaggi:

Crea il portachiavi

security create-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"

a questo punto il portachiavi è sbloccato ma non verrà visualizzato Keychain Access.

Aggiungi il nuovo portachiavi all'elenco di ricerca

security list-keychains -s "${KEYCHAIN_NAME}" "${OLD_KEYCHAIN_NAMES[@]}"

Aggiungi il nuovo portachiavi all'elenco. Se non prendi prima la lista originale da list-keychainsnon avrai più login.keychainnella tua lista di ricerca.

Sblocca il portachiavi

security unlock-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"

Questo è ridondante se hai creato il Portachiavi sopra, ma se il Portachiavi esisteva già è necessario.

Rimuovi i valori predefiniti dal portachiavi

security set-keychain-settings "${TESTING_KEYCHAIN}"

Non specificando alcun argomento, il timeout del blocco automatico verrà impostato su illimitato e verrà rimosso il blocco automatico in modalità sospensione.

Importa i certificati di firma da un .p12

security import "${DIST_CER}" -P "${CERTIFICATE_PASSWORD}" -k "${KEYCHAIN_NAME}" -T /usr/bin/codesign

Importa i certificati e consente l' codesignaccesso tramite l' -Topzione.

Imposta l'ACL sul portachiavi

security set-key-partition-list -S apple-tool:,apple: -s -k "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"

Questo è un requisito che molte persone mancano. Puoi vedere cosa fa macOS usando dump-keychain. Che nel caso della codifica richiede apple:e apple-tool:. -ssi riferisce alla firma dei certificati.

Gitlab-Runner, Jenkins e simili

Una cosa molto importante per qualsiasi corridore di tipo CI o sistema di compilazione è assicurarsi che il processo sia avviato launchdcorrettamente. Assicurati che il tuo plist contenga <SessionCreate> </true>.

Non abbinare correttamente il proprietario del portachiavi con il processo di generazione e assicurarsi che venga creata una sessione di sicurezza comporterà tutti i tipi di mal di testa. Dal punto di vista diagnostico puoi presentare list-keychainse vedere se l'output soddisfa le tue aspettative.

Questo è dalla launchd.plistpagina man:

SessionCreate <boolean>

Questa chiave specifica che il lavoro deve essere generato in una nuova sessione di controllo della sicurezza piuttosto che la sessione predefinita per il contesto appartiene. Vedere auditon (2) per i dettagli.

UserName <string>

Questa chiave opzionale specifica l'utente per eseguire il lavoro come. Questa chiave è applicabile solo per i servizi caricati nel dominio di sistema privilegiato.

GroupName <string>

Questa chiave opzionale specifica il gruppo in cui eseguire il lavoro. Questa chiave è applicabile solo per i servizi caricati nel dominio di sistema privilegiato. Se UserName è impostato e GroupName non lo è, il gruppo verrà impostato sul gruppo primario dell'utente.

Finalmente il codesign

È possibile cercare l'hash dei certificati di firma utilizzando find-identity

security find-identity -p codesigning -v

Codifica un framework, dylib, ecc.

/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" "$SIGNABLE"

Codifica il pacchetto dell'app

/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" --entitlements entitlements.xcent "$SIGNABLE"

Note finali - se guardi come Xcode lo fa, CODESIGN_ALLOCATEusano per usare quello contenuto in Xcode, non in /usr/bin.

export CODESIGN_ALLOCATE="$( xcrun --find codesign_allocate )"

Il percorso di ricerca è impostato su ${PLATFORM_PATH}:${TOOLCHAIN_PATH}:${PATH}, dove il percorso PLATFORM è la directory / usr / bin per l'SDK di destinazione specificato e TOOLCHAIN_PATH è il / usr / bin per gli strumenti host Xcode.

Inserisci le tue chiavi nel portachiavi di sistema

Quindi questo è il comando che funziona. -Aè impedire al Mac di chiedere la password. L'importazione in system.keychain non richiede una GUI.

sudo security import <cert.p12> -k "/Library/Keychains/System.keychain" -P <passphrase> -A

Il mio portachiavi era bloccato. Ha resistito ai miei progressi per cambiare questo fatto ...

Keychain Access-> Keychain First Aid-> Repair, et voilá !

Sbloccare il portachiavi non è abbastanza. Devi anche impostare l'accesso della chiave privata su "Consenti a tutte le app di accedere a questo elemento". E per farlo dalla riga di comando è necessario reimportare la chiave. Quindi, per prendere le cose alla volta:

Sblocca il portachiavi di accesso se è bloccato. Tuttavia, non dovrebbe essere bloccato, ma ecco come si fa:

security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "~/Library/Keychains/login.keychain"

Se per qualche motivo la tua macchina di compilazione ha il portachiavi di accesso bloccato e non vuoi esporre quella password in uno script, allora dovresti usare un portachiavi diverso. Puoi crearne uno sul posto e utilizzarlo nel comando precedente e seguente. Per crearne uno sul posto:

security create-keychain -p 'temporaryPassword' MyKeychain.keychain
security list-keychains -d user -s login.keychain MyKeychain.keychain

Quindi importare i certificati e le chiavi private associate nel portachiavi di accesso utilizzando il parametro -A. Nota che non è necessario sudo per tutto questo ...

security import <cert.p12> -k "~/Library/Keychains/login.keychain" -P <passphrase> -A

Il parametro -A è ciò che renderà la tua chiave privata impostata su "Consenti a tutte le app di accedere a questo elemento"

Quindi, usando tutti questi, dovresti essere in grado di creare uno script che installa il certificato richiesto per creare un rilascio ipa e firmarlo senza prompt. Puoi archiviare il file .p12 nel tuo repository, in modo che qualsiasi macchina possa creare il tuo ipa senza richiedere la configurazione manuale.

Oltre allo sblocco del portachiavi (come menzionato in altre risposte), devi consentire l'accesso da tutte le applicazioni al token di autenticazione Xcode nel portachiavi:

• Seleziona il portachiavi "login"
• Seleziona la categoria "Tutti gli articoli"
• Cerca la parola chiave "xcode"
• Seleziona "Consenti a tutte le applicazioni di accedere a questo elemento" per tutti i token Xcode
• Non dimenticare di aggiungere il passaggio per sbloccare il portachiavi (dalle risposte precedenti)

Importa le tue chiavi nel portachiavi di sistema. Puoi usare questo comando:

sudo security import YourKey.p12 -k /Library/Keychains/System.keychain -P PasswordToYourKey -T /usr/bin/codesign

Quindi ho provato tutte le risposte qui e qualcosa non andava bene. Alla fine ho capito quando ho riavviato il mio servizio CI, era in esecuzione con un utente diverso da quello che mi aspettavo. Il passaggio all'utente che aveva effettivamente accesso alla chiave nella catena di accesso ha risolto tutto. Questo potrebbe non essere un problema comune, ma volevo documentare il mio motivo specifico per questo errore, nel caso in cui accada ad altri.

Per me nulla ha funzionato sembra dover reinstallare nuovamente Xcode. Jenkins continua a dare lo stesso errore. Risparmieresti molto tempo spostando l'installazione di Xcode nel Cestino e reinstallandolo. Assicurarsi di eseguire almeno una volta il comando codesign dalla riga di comando.

Anche dopo aver riscontrato lo stesso errore, prova a impostare "Sblocca portachiavi?" proprietà all'interno di Jenkins e indica il percorso del tuo login.keychain in /Users/${USER}/Library/Keychains/login.keychain

Spero che Dio sia con te dopo quello.

Nel mio caso, ciò è stato causato dalla creazione di un portachiavi con un timeout predefinito di 300 secondi e una lunga compilazione di xcode della durata di oltre 300 secondi. La soluzione alternativa, per me, era invocare:

security set-keychain-settings -t <longer timeout in seconds> <keychain>

subito dopo aver creato il portachiavi temporaneo.

Ho seguito tutti questi suggerimenti e continuavo a riscontrare problemi nell'uso di Fastlane gymin un lavoro di Jenkins. Avevo installato il certificato e sbloccato il portachiavi ed ero in grado di eseguire la firma dei codici sullo slave quando ho eseguito manualmente il comando di progettazione dei segni sulla riga di comando.

Per ovviare a questo problema, se Jenkins si connette allo slave tramite JNLP anziché SSH, sarai in grado di codificare i codici.

Per me succede quando c'è un secondo portachiavi aggiunto manualmente ed è bloccato. Per qualche motivo codesigntenta di accedere al portachiavi bloccato e non riesce anche se i certificati si trovano nel portachiavi di accesso (ed è sbloccato). Lo sblocco del secondo risolve il problema. Solo non ha senso per me.

Dopo aver provato una serie di soluzioni di cui sopra. Mi sono reso conto che un fattore che avevo, era che stavo iniziando la compilazione usando la console ION. Quando sono tornato a creare la build dall'app Terminal, tutto ha funzionato bene.