Unser automatisierter Build läuft auf Jenkins. Der Build selbst wird auf Slaves ausgeführt, wobei die Slaves über SSH ausgeführt werden.

Ich erhalte eine Fehlermeldung:

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

Ich habe jeden Vorschlag ausprobiert, den ich bisher in anderen Posts hier gesehen habe:

• Verwenden Sie den Sicherheits-Unlock-Schlüsselbund unmittelbar vor dem Signieren, um den Schlüsselbund zu entsperren.
• Verschieben des Signaturschlüssels in einen eigenen Schlüsselbund.
• Verschieben des Signaturschlüssels in den Anmeldeschlüsselbund.
• Verschieben des Signaturschlüssels in den Systemschlüsselbund.
• Manuelles Festlegen von Listen-Schlüsselanhängern nur für den Schlüsselbund, der den Schlüssel enthält.

In allen Fällen erhalte ich den gleichen Fehler.

Bei dem Versuch, das Problem zu diagnostizieren, habe ich versucht, den Befehl "Security Unlock-Keychain" auf meinem lokalen Terminal auszuführen, und festgestellt, dass der Schlüsselbund dadurch nicht entsperrt wird. Wenn ich in Keychain Access nachschaue, ist das Schlosssymbol immer noch vorhanden. Dies ist der Fall, unabhängig davon, ob ich das Kennwort in der Befehlszeile übergebe oder ob ich dazu aufgefordert werde. Wenn Sie denselben Schlüsselbund über die GUI entsperren, werde ich zur Eingabe des Kennworts aufgefordert und anschließend entsperrt. Außerdem, wenn ich „Sicherheitsschloss-Schlüsselband“ laufen, ich tue um die Tastensperre sehen unmittelbar nach dem Ausführen des Befehls. Dies lässt mich denken, dass das Entsperren des Schlüsselbunds nicht wirklich funktioniert. Ich habe das gleiche Verhalten bei Lion (das wir für die Build-Slaves verwenden) und Mavericks (das ich entwickle).

Als nächstes habe ich versucht, allen Sicherheitsbefehlen -v hinzuzufügen:

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.

Aus diesem Grund scheint es, dass List-Keychains nicht funktionieren. Vielleicht funktioniert beides nicht. : /

Hier gibt es eine ähnliche Frage . Die Lösung ist interessant - setzen Sie "SessionCreate" in launchctl auf true. Aber ich baue nicht auf dem Master auf - mein Erstellungsprozess wird von SSH auf einer Slave-Erstellungsmaschine gestartet. Vielleicht gibt es eine Befehlszeilenmethode, um das zu tun, was launchctl tut, wenn Sie "SessionCreate" ausführen?

Auch ich habe dagegen gekämpft. Nichts half, bis ich den Vorschlag auf http://devnet.jetbrains.com/thread/311971 ausprobierte . Vielen Dank, Ashish Agrawal!

Melden Sie Ihren Build-Benutzer über die GUI an und öffnen Sie den Schlüsselbundzugriff. Wählen Sie Ihren privaten Signaturschlüssel aus, klicken Sie mit der rechten Maustaste, wählen Sie "Informationen abrufen", wechseln Sie zur Registerkarte "Zugriffssteuerung" und wählen Sie "Allen Anwendungen erlauben, auf dieses Element zuzugreifen".

Nun, ich schätze, ich kann heute meine eigene Frage beantworten, denn nachdem ich über zweieinhalb Tage darauf gestochen habe, scheint eines der Dinge, die ich versucht habe, funktioniert zu haben. Ich werde mich jetzt einfach zurückziehen und hoffe, dass es weiter funktioniert.

Im Wesentlichen sieht es so aus, als ob es darauf ankommt, -d systemnicht wirklich zu funktionieren. Daher sollten wahrscheinlich viele Antworten auf andere Fragen hier aktualisiert werden, um dies widerzuspiegeln.

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"

Keine der anderen Antworten hat bei mir funktioniert.

Was mich schließlich gerettet hat, war dieser Beitrag

Zusammenfassend kann dies durch ein Standardzeitlimit von 5 Minuten verursacht werden, das diesen Fehler nach einem langen Build auslöst.

Reparieren:

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

Versuchen Sie, security unlock-keychainund codesignals einzeiligen Befehl aufzurufen . Das hat mir geholfen. Etwas wie:

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

Verwenden von Sicherheit zum Erstellen eines Schlüsselbunds für / usr / bin / Codesign

Das Zertifikat zu importieren und programmgesteuert mit Codesign arbeiten zu lassen, bedeutet nicht, Login- oder System-Schlüsselanhänger zu verwenden oder zu einem Gott des Codesigns zu beten. Sie müssen nur die richtigen Berechtigungen festlegen. Ich empfehle, einen neuen Schlüsselbund speziell für Codesign-Zwecke zu erstellen.

In diesen Tagen zu erhalten , codesignum nicht nachgeben errSecInternalComponentmüssen Sie die Partitionsliste (ACLs) korrekt zu erhalten. Ich werde durch die Stufen gehen:

Erstellen Sie den Schlüsselbund

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

Zu diesem Zeitpunkt ist der Schlüsselbund entsperrt, wird jedoch nicht angezeigt Keychain Access.

Fügen Sie den neuen Schlüsselbund zur Suchliste hinzu

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

Fügen Sie den neuen Schlüsselbund zur Liste hinzu. Wenn Sie die ursprüngliche Liste nicht zuerst herausnehmen, haben list-keychainsSie sie nicht mehr login.keychainin Ihrer Suchliste.

Entsperren Sie den Schlüsselbund

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

Dies ist redundant, wenn Sie den obigen Schlüsselbund erstellt haben. Wenn der Schlüsselbund jedoch bereits vorhanden ist, ist dies erforderlich.

Entfernen Sie die Standardeinstellungen aus dem Schlüsselbund

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

Wenn Sie keine Argumente angeben, wird das Zeitlimit für die automatische Sperre auf unbegrenzt gesetzt und die automatische Sperre im Ruhezustand entfernt.

Importieren Sie Ihre Signaturzertifikate von einer .p12

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

Importieren Sie die Zertifikate und gewähren Sie codesignZugriff über die -TOption.

Legen Sie die ACL am Schlüsselbund fest

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

Dies ist eine Anforderung, die viele Menschen vermissen. Sie können sehen, was macOS macht, indem Sie den Dump-Schlüsselbund verwenden. Was im Fall von Codesigning erfordert apple:und apple-tool:. -sbezieht sich auf das Signieren von Zertifikaten.

Gitlab-Runner, Jenkins und dergleichen

Eine sehr wichtige Sache für jeden CI-Runner oder jedes Build-System ist es, sicherzustellen, dass der Prozess launchdkorrekt gestartet wird. Stellen Sie sicher, dass Ihre Liste enthält <SessionCreate> </true>.

Wenn der Eigentümer des Schlüsselbunds nicht korrekt mit dem Erstellungsprozess übereinstimmt und sichergestellt wird, dass eine Sicherheitssitzung erstellt wird, kann dies zu Kopfschmerzen führen. Diagnostisch gesehen können Sie vorstellen, list-keychainsob die Ausgabe Ihren Erwartungen entspricht.

Dies ist von der launchd.plistManpage:

SessionCreate <boolean>

Dieser Schlüssel gibt an, dass der Job in einer neuen Sicherheitsüberwachungssitzung erzeugt werden soll und nicht in der Standardsitzung, zu der der Kontext gehört. Siehe Auditon (2) für Details.

UserName <string>

Dieser optionale Schlüssel gibt den Benutzer an, unter dem der Job ausgeführt werden soll. Dieser Schlüssel gilt nur für Dienste, die in die privilegierte Systemdomäne geladen werden.

GroupName <string>

Dieser optionale Schlüssel gibt die Gruppe an, unter der der Job ausgeführt werden soll. Dieser Schlüssel gilt nur für Dienste, die in die privilegierte Systemdomäne geladen werden. Wenn Benutzername festgelegt ist und Gruppenname nicht, wird die Gruppe auf die primäre Gruppe des Benutzers festgelegt.

Endlich Codesign

Sie können den Hash der Signaturzertifikate mit nachschlagen find-identity

security find-identity -p codesigning -v

Codesignieren Sie ein Framework, eine Dylib usw.

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

Codesignieren Sie das App-Bundle

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

Schlussbemerkungen - Wenn Sie sich ansehen, wie Xcode dies tut, wird festgelegt CODESIGN_ALLOCATE, dass der in Xcode enthaltene verwendet wird, nicht in /usr/bin.

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

Der Suchpfad ist auf festgelegt ${PLATFORM_PATH}:${TOOLCHAIN_PATH}:${PATH}, wobei der PLATFORM-Pfad das Verzeichnis / usr / bin für das angegebene Ziel-SDK und TOOLCHAIN_PATH das Verzeichnis / usr / bin für die Xcode-Host-Tools ist.

Legen Sie Ihre Schlüssel in den Systemschlüsselbund

Das ist also der Befehl, der funktioniert. -Asoll verhindern, dass der Mac nach dem Passwort fragt. Für den Import in system.keychain ist keine GUI erforderlich.

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

Mein Schlüsselbund war verschlossen. Es widerstand meinen Fortschritten, diese Tatsache zu ändern ...

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

Das Entsperren des Schlüsselbunds reicht nicht aus. Sie müssen auch den Zugriff auf den privaten Schlüssel auf "Allen Apps den Zugriff auf dieses Element erlauben" setzen. Um dies über die Befehlszeile zu tun, muss der Schlüssel erneut importiert werden. Also, um Dinge auf einmal zu nehmen:

Entsperren Sie den Anmeldeschlüsselbund, wenn er gesperrt ist. Es sollte zwar nicht gesperrt sein, aber so machen Sie das:

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

Wenn auf Ihrem Buildcomputer der Anmeldeschlüsselbund gesperrt ist und Sie dieses Kennwort nicht in einem Skript verfügbar machen möchten, sollten Sie einen anderen Schlüsselbund verwenden. Sie können eine sofort erstellen und diese im vorherigen und folgenden Befehl verwenden. So erstellen Sie eine vor Ort:

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

Importieren Sie dann Ihre Zertifikate und zugehörigen privaten Schlüssel mit dem Parameter -A in den Anmeldeschlüsselbund. Beachten Sie, dass Sie für all dies kein Sudo benötigen ...

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

Mit dem Parameter -A wird Ihr privater Schlüssel auf "Alle Apps dürfen auf dieses Element zugreifen" gesetzt.

Wenn Sie all diese Funktionen verwenden, sollten Sie in der Lage sein, ein Skript zu erstellen, das das erforderliche Zertifikat installiert, um eine Release-IPA zu erstellen und ohne Aufforderung zu signieren. Sie können die .p12-Datei in Ihrem Repo speichern, sodass jeder Computer Ihre IPA erstellen kann, ohne dass eine manuelle Einrichtung erforderlich ist.

Abgesehen vom Entsperren des Schlüsselbunds (wie in anderen Antworten erwähnt) müssen Sie den Zugriff aller Anwendungen auf das Xcode-Authentifizierungstoken im Schlüsselbund zulassen:

• Wählen Sie den Schlüsselbund "Login"
• Wählen Sie die Kategorie "Alle Artikel"
• Suchen Sie nach dem Schlüsselwort "xcode"
• Wählen Sie für alle Xcode-Token "Allen Anwendungen erlauben, auf dieses Element zuzugreifen"
• Vergessen Sie nicht, den Schlüsselbund zum Entsperren hinzuzufügen (aus früheren Antworten).

Importieren Sie Ihre Schlüssel in den Systemschlüsselbund. Sie können diesen Befehl verwenden:

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

Also habe ich hier jede Antwort ausprobiert und etwas stimmte nicht ganz. Als ich meinen CI-Dienst neu startete, stellte ich schließlich fest, dass er unter einem anderen Benutzer ausgeführt wurde, als ich erwartet hatte. Der Wechsel zu dem Benutzer, der tatsächlich Zugriff auf den Schlüssel in seiner Anmeldekette hatte, hat alles behoben. Dies ist möglicherweise kein häufiges Problem, wollte aber meinen spezifischen Grund für diesen Fehler dokumentieren, falls es anderen passiert.

Für mich scheint nichts geklappt zu haben, Xcode neu zu installieren. Jenkins gibt immer wieder den gleichen Fehler. Sie würden viel Zeit sparen, wenn Sie die Xcode-Installation einfach in den Papierkorb verschieben und neu installieren. Stellen Sie sicher, dass Sie den Befehl Codesign mindestens einmal über die Befehlszeile ausführen.

Auch wenn Sie den gleichen Fehler erhalten, versuchen Sie, "Schlüsselbund entsperren?" Eigenschaft in Jenkins und geben Sie den Pfad zu Ihrer login.keychain unter /Users/${USER}/Library/Keychains/login.keychain an

Ich hoffe, Gott ist danach bei dir.

In meinem Fall wurde dies dadurch verursacht, dass ein Schlüsselbund mit einem Standardzeitlimit von 300 Sekunden und einer langen Xcode-Kompilierung von mehr als 300 Sekunden erstellt wurde. Die Problemumgehung bestand für mich darin, Folgendes aufzurufen:

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

unmittelbar nach dem Erstellen des temporären Schlüsselbunds.

Ich habe all diese Vorschläge durchgearbeitet und hatte immer noch Probleme, Fastlanes gymin einem Jenkins-Job zu verwenden. Ich hatte das Zertifikat installiert und den Schlüsselbund entsperrt und konnte auf dem Slave Codesignieren, als ich den Befehl Codesign in der Befehlszeile manuell ausführte.

Umgehung: Wenn Jenkins über JNLP anstelle von SSH eine Verbindung zum Slave herstellt, können Sie ein Codesign erstellen.

Bei mir passiert es, wenn ein zweiter Schlüsselbund manuell hinzugefügt und gesperrt wird. Aus irgendeinem Grund wird codesignversucht, auf den gesperrten Schlüsselbund zuzugreifen, und dies schlägt fehl, obwohl sich die Zertifikate im Anmeldeschlüsselbund befinden (und entsperrt sind). Das Entsperren des zweiten löst das Problem. Macht für mich einfach keinen Sinn.

Nachdem Sie eine Reihe der oben genannten Lösungen ausprobiert haben. Ich erkannte, dass ein Faktor, den ich hatte, war, dass ich den Build mit der ION-Konsole startete. Als ich wieder zum Erstellen über die Terminal-App wechselte, funktionierte alles einwandfrei.