"Benutzerinteraktion ist nicht zulässig" versucht, eine OSX-App mit Codesign zu signieren
Unser automatisierter Build läuft auf Jenkins. Der Build selbst läuft auf Slaves, wobei die Slaves über SSH ausgeführt werden.
Ich erhalte einen Fehler:
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 unmittelbar vor dem Signieren den Sicherheitsschlüsselbund, 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 Setzen von list-keychains auf 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 nicht tatsächlich entsperrt wird. Wenn ich in "Keychain Access" nachschaue, ist das Schlosssymbol immer noch vorhanden. Dies ist der Fall, wenn ich das Kennwort in der Befehlszeile übergebe oder wenn ich es zur Eingabe auffordern lasse. Wenn Sie denselben Schlüsselbund über die GUI entsperren, werden Sie zur Eingabe des Kennworts aufgefordert und anschließend entsperrt. Wenn ich außerdem "security lock-keychain" ausführe, sehe ich do die Tastensperre unmittelbar nach dem Ausführen des Befehls. Das lässt mich denken, dass Unlock-Keychain nicht wirklich funktioniert. Ich erlebe das gleiche Verhalten bei Lion (das wir für die Build-Slaves verwenden) und Mavericks (auf denen ich mich entwickle).
Als Nächstes habe ich versucht, -v zu allen Sicherheitsbefehlen 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 Listenschlüsselanhänger nicht funktionieren. Vielleicht funktioniert beides nicht. : /
Es gibt eine ähnliche Frage hier . Die Lösung ist interessant - setzen Sie "SessionCreate" in launchctl auf "true". Aber ich baue nicht auf dem Master auf - mein Build-Prozess wird von SSH auf einer Slave-Build-Maschine gestartet. Vielleicht gibt es eine Befehlszeilenmethode, um das zu tun, was launchctl macht, wenn Sie "SessionCreate" ausführen?
Nun, ich schätze, ich kann heute meine eigene Frage beantworten, denn nachdem ich sie zweieinhalb Tage lang erstochen habe, scheint eines der Dinge, die ich versucht habe, zu funktionieren. Ich werde mich jetzt einfach zurückziehen und hoffe, dass es weiter funktioniert.
Im Grunde sieht es so aus, als würde -d system nicht funktionieren. Daher sollten viele Antworten auf andere Fragen hier möglicherweise aktualisiert werden.
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"
Ich habe auch das bekämpft. Nichts half, bis ich den Vorschlag auf http://devnet.jetbrains.com/thread/311971 ausprobierte. Danke, Ashish Agrawal!
Melden Sie sich über die GUI bei Ihrem Build-Benutzer an und öffnen Sie Keychain Access. 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 den Zugriff auf dieses Element zulassen".
Keine der anderen Antworten funktionierte für mich.
Was mich schließlich rettete war dieser Beitrag
Zusammenfassend kann dies durch ein Standard-Timeout 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-keychain und codesign als einzeiligen Befehl aufzurufen. Das hat mir geholfen. So etwas wie:
security unlock-keychain -p <password> /Users/<user>/Library/Keychains/login.keychain && codesign --force --verify --verbose --sign "<certificate id>" <app name>
Legen Sie Ihre Schlüssel in den Systemschlüsselbund
Das ist also der Befehl, der funktioniert. -A soll verhindern, dass Mac nach einem Kennwort 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
Verwenden der Sicherheit zum Erstellen eines Schlüsselbunds für/usr/bin/codesign
Beim Importieren des Zertifikats und dessen programmgesteuerter Verwendung mit Codesign müssen Sie nicht das Login oder System-Schlüsselbunde verwenden oder zu einem Gott des Codesigns beten. Sie müssen nur die richtigen Berechtigungen festlegen. Ich empfehle, einen neuen Schlüsselbund speziell für Codesign-Zwecke zu erstellen.
Um codesign zu erhalten, um keine errSecInternalComponent zu erhalten, müssen Sie die Partitionsliste (ACLs) richtig einstellen. Ich gehe durch die Stufen:
Erstellen Sie den Schlüsselbund
security create-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"
zu diesem Zeitpunkt ist der Schlüsselbund entsperrt, erscheint aber nicht in Keychain Access.
Fügen Sie der Suchliste den neuen Schlüsselbund hinzu
security list-keychains -s "${KEYCHAIN_NAME}" "${OLD_KEYCHAIN_NAMES[@]}"
Fügen Sie der Liste den neuen Schlüsselbund hinzu. Wenn Sie die ursprüngliche Liste nicht zuerst aus list-keychains herausholen, haben Sie login.keychain nicht mehr in Ihrer Suchliste.
Entsperren Sie den Schlüsselbund
security unlock-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"
Dies ist überflüssig, wenn Sie den Schlüsselbund oben erstellt haben. Ist der Schlüsselbund jedoch bereits vorhanden, ist er erforderlich.
Entfernen Sie die Standardwerte 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 für den Ruhezustand aufgehoben.
Importieren Sie Ihre Signaturzertifikate von einem .p12
security import "${DIST_CER}" -P "${CERTIFICATE_PASSWORD}" -k "${KEYCHAIN_NAME}" -T /usr/bin/codesign
Importieren Sie die Zertifikate und gewähren Sie codesign Zugriff über die Option -T.
Legen Sie die ACL für den 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 mit Hilfe von dump-keychain sehen, was macOS macht. Was im Falle der Codesignierung Apple: und Apple-tool: erfordert. -s bezieht sich auf das Signieren von Zertifikaten.
Gitlab-Runner, Jenkins und dergleichen
Für alle CI-Läufer oder Build-Systeme ist es sehr wichtig, sicherzustellen, dass der Prozess korrekt von launchd gestartet wird. Stellen Sie sicher, dass Ihre Liste <SessionCreate> </true> enthält.
Wenn der Eigentümer des Schlüsselbundes nicht korrekt mit dem Erstellungsprozess abgeglichen wird und sichergestellt wird, dass eine Sicherheitssitzung erstellt wird, führt dies zu allen möglichen Kopfschmerzen. Diagnostisch können Sie list-keychains einführen und sehen, ob die Ausgabe Ihren Erwartungen entspricht.
Dies ist von der launchd.plist-Manpage:
SessionCreate <boolean>
Dieser Schlüssel gibt an, dass der Job in einer neuen Sicherheit erstellt werden soll Prüfsitzung und nicht die Standardsitzung für den Kontext gehört zu. Weitere Informationen finden Sie in Auditon (2).
UserName <string>
Dieser optionale Schlüssel gibt den Benutzer an, als den Job auszuführen. Dieser Schlüssel ist nur anwendbar für Dienste, die in das privilegierte System geladen werden Domain.
GroupName <string>
Dieser optionale Schlüssel gibt die Gruppe an, unter der der Job ausgeführt werden soll. Dieser Schlüssel ist nur anwendbar für Dienste, die in das privilegierte System geladen werden Domain. Wenn UserName festgelegt ist und GroupName nicht, lautet die Gruppe auf die primäre Gruppe des Benutzers eingestellt.
Endlich codieren
Sie können den Hash der Signaturzertifikate mit find-identity nachschlagen.
security find-identity -p codesigning -v
Kennzeichnen Sie einen Rahmen, Dylib usw.
/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" "$SIGNABLE"
Codieren Sie das App-Paket
/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" --entitlements entitlements.xcent "$SIGNABLE"
Abschließende Notizen - Wenn Sie sich die Funktionsweise von Xcode ansehen, wird CODESIGN_ALLOCATE so eingestellt, dass der in Xcode enthaltene Code verwendet wird, nicht in /usr/bin.
export CODESIGN_ALLOCATE="$( xcrun --find codesign_allocate )"
Der Suchpfad ist auf ${PLATFORM_PATH}:${TOOLCHAIN_PATH}:${PATH} gesetzt, wobei PLATFORM-Pfad das Verzeichnis/usr/bin für das angegebene Ziel-SDK ist und TOOLCHAIN_PATH das Verzeichnis/usr/bin für die Xcode-Host-Tools.
Mein Schlüsselbund war verschlossen. Es widerstanden meine Fortschritte, 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 "Zugriff auf alle Elemente für alle Apps zulassen" festlegen. Um dies über die Befehlszeile zu tun, muss der Schlüssel erneut importiert werden. Also, um Dinge auf einmal zu nehmen:
Entsperren Sie den Login-Schlüsselbund, wenn er gesperrt ist. Es sollte zwar nicht gesperrt sein, aber wie folgt:
security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "~/Library/Keychains/login.keychain"
Wenn aus irgendeinem Grund der Anmelde-Schlüsselbund in Ihrem Build-Computer 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 vor Ort eines erstellen und das im vorherigen und im folgenden Befehl verwenden. So erstellen Sie vor Ort:
security create-keychain -p 'temporaryPassword' MyKeychain.keychain
security list-keychains -d user -s login.keychain MyKeychain.keychain
Importieren Sie anschließend Ihre Zertifikate und zugehörigen privaten Schlüssel mit dem Parameter -A in den Login-Schlüsselbund. Beachten Sie, dass Sie für all das nicht Sudo brauchen ...
security import <cert.p12> -k "~/Library/Keychains/login.keychain" -P <passphrase> -A
Mit dem Parameter -A wird der private Schlüssel auf "Alle Apps darf auf dieses Element zugreifen" gesetzt.
Daher sollten Sie in der Lage sein, ein Skript zu erstellen, das das erforderliche Zertifikat zum Erstellen eines Release-IPs installiert und ohne Aufforderung signiert. Sie können die .p12-Datei in Ihrem Repo speichern, sodass jede Maschine Ihre ipa ohne manuelle Einrichtung erstellen kann.
Also habe ich hier jede Antwort ausprobiert und etwas passte nicht so ganz zusammen. Als ich schließlich meinen CI-Dienst neu startete, fand ich heraus, dass er unter einem anderen Benutzer lief als erwartet. Durch den Wechsel zu dem Benutzer, der tatsächlich Zugriff auf den Schlüssel in der Login-Kette hatte, wurde alles behoben. Dies ist möglicherweise kein allgemeines Problem, aber ich wollte meinen spezifischen Grund für diesen Fehler dokumentieren, falls es anderen passiert.
Importieren Sie Ihre Schlüssel in das System-Schlüsselbund. Sie können diesen Befehl verwenden:
Sudo security import YourKey.p12 -k /Library/Keychains/System.keychain -P PasswordToYourKey -T /usr/bin/codesign
Für mich passiert es, wenn ein zweiter Schlüsselbund manuell hinzugefügt wird und dieser gesperrt ist. Aus irgendeinem Grund versucht codesign, auf den gesperrten Schlüsselbund zuzugreifen und schlägt fehl, obwohl sich die Zertifikate im Anmeldeschlüsselbund befinden (und nicht gesperrt sind). Das Entsperren des zweiten löst das Problem. Nur macht für mich keinen Sinn.
In meinem Fall wurde dies durch einen Schlüsselbund verursacht, der mit einem Standard-Timeout von 300s und einem langen Xcode-Compile von mehr als 300s erstellt wurde. Die Problemumgehung bestand für mich aus:
security set-keychain-settings -t <longer timeout in seconds> <keychain>
unmittelbar nach dem Erstellen des temporären Schlüsselbundes.
Für mich hat nichts funktioniert, scheint Xcode noch einmal neu zu installieren. Jenkins gibt immer wieder die gleiche Fehlermeldung aus. Sie würden viel Zeit sparen, wenn Sie die Xcode-Installation einfach in den Papierkorb verschieben und erneut installieren. Stellen Sie sicher, dass Sie den Befehl codesign mindestens einmal über die Befehlszeile ausführen.
Selbst wenn Sie die gleiche Fehlermeldung erhalten, versuchen Sie, "Unlock Keychain?" Eigenschaft in Jenkins und geben Sie den Pfad zu login.keychain unter /Users/${USER}/Library/Keychains/login.keychain an
Ich hoffe, dass Gott danach bei dir sein wird.
Ich habe all diese Vorschläge durchgearbeitet und hatte immer noch Probleme, die gym von fastlane in einem Jenkins-Job zu verwenden. Ich hatte das Zertifikat installiert und den Schlüsselbund entsperrt, und konnte den Slave codieren, als ich den CodeSign-Befehl in der Befehlszeile manuell ausführte.
Als Problemumgehung können Sie, wenn Jenkins eine Verbindung mit dem Slave über JNLP anstelle von SSH herstellt, eine Codierung vornehmen.
Abgesehen vom Entsperren des Schlüsselbunds (wie in anderen Antworten erwähnt) müssen Sie allen Anwendungen den Zugriff auf das Xcode-Authentifizierungstoken im Schlüsselbund erlauben:
- Wählen Sie "Login" Schlüsselbund
- Wählen Sie die Kategorie "Alle Artikel"
- Suche nach "xcode" Stichwort
- Wählen Sie für alle Xcode-Token "Allen Anwendungen den Zugriff auf dieses Element erlauben"
- Vergessen Sie nicht, den Schritt zum Entsperren des Schlüsselbunds (aus vorherigen Antworten) hinzuzufügen.
