Nasza zautomatyzowana kompilacja działa na Jenkins. Sama kompilacja działa na niewolnikach, a niewolnicy są wykonywane przez SSH.

Pojawia się błąd:

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

Wypróbowałem każdą sugestię, którą do tej pory widziałem w innych postach tutaj:

• Użycie bezpieczeństwa odblokowania pęku kluczy bezpośrednio przed podpisaniem w celu odblokowania pęku kluczy.
• Przeniesienie klucza podpisywania do własnego pęku kluczy.
• Przeniesienie klucza podpisu do pęku kluczy logowania.
• Przeniesienie klucza podpisywania do pęku kluczy systemu.
• Ręczne ustawianie list-pęków kluczy tylko do pęku kluczy, który zawiera klucz.

We wszystkich przypadkach pojawia się ten sam błąd.

Próbując zdiagnozować problem, próbowałem uruchomić polecenie „security unlock-keychain” na moim lokalnym terminalu i stwierdziłem, że w rzeczywistości nie odblokowuje ono pęku kluczy - jeśli spojrzę w Dostęp do pęku kluczy, symbol blokady nadal tam jest. Dzieje się tak, niezależnie od tego, czy podaję hasło w wierszu poleceń, czy też pozwolę, aby monit o to. Odblokowanie tego samego pęku kluczy za pomocą GUI spowoduje wyświetlenie monitu o hasło, a następnie odblokowanie go. Dodatkowo, jeśli uruchomię „security lock-keychain”, to zrobić patrz blokadę natychmiast po uruchomieniu komendy. To sprawia, że ​​myślę, że odblokowanie pęku kluczy tak naprawdę nie działa. Doświadczam tego samego zachowania na Lion (którego używamy dla niewolników kompilacji) i Mavericks (na którym rozwijam).

Następnie spróbowałem dodać -v do wszystkich poleceń bezpieczeństwa:

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.

Z tego wynika, że ​​lista-pęków kluczy jest tym, co nie działa. Może nie działa. : /

Tutaj jest podobne pytanie . Rozwiązanie jest interesujące - ustaw „SessionCreate” na true w launchctl. Ale nie opieram się na master - mój proces kompilacji jest uruchamiany z SSH na maszynie do kompilacji slave. Może istnieje sposób z wiersza poleceń, aby zrobić to, co robi launchctl po uruchomieniu „SessionCreate”?

Ja też z tym walczyłem. Nic nie pomogło, dopóki nie wypróbowałem sugestii na http://devnet.jetbrains.com/thread/311971 . Dzięki ashish agrawal!

Zaloguj się do użytkownika kompilacji za pośrednictwem interfejsu GUI i otwórz dostęp do pęku kluczy. Wybierz swój klucz prywatny podpisu, kliknij prawym przyciskiem myszy, wybierz Uzyskaj informacje, przejdź do zakładki Kontrola dostępu i wybierz opcję „Zezwalaj wszystkim aplikacjom na dostęp do tego elementu”.

Cóż, wydaje mi się, że dziś odpowiem na swoje pytanie, ponieważ po dźgnięciu go przez dwa i pół dnia jedna z rzeczy, których próbowałem, zadziałała. Zamierzam się teraz od tego wycofać i mam nadzieję, że nadal będzie działać.

Zasadniczo wygląda na to, że tak -d systemnaprawdę nie działa. Tak więc wiele odpowiedzi na inne pytania powinno prawdopodobnie zostać zaktualizowanych, aby to odzwierciedlić.

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"

Żadna z pozostałych odpowiedzi nie działała dla mnie.

Tym, co ostatecznie uratowało mnie, był ten post

Podsumowując, może to być spowodowane domyślnym limitem czasu wynoszącym 5 minut, który wywoła ten błąd po długiej kompilacji.

Naprawić:

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

Spróbuj zadzwonić security unlock-keychaini codesignjako polecenie jednowierszowe. To mi pomogło. Coś jak:

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

Używanie zabezpieczeń do tworzenia pęku kluczy dla / usr / bin / codign

Zaimportowanie certyfikatu i zaprogramowanie go na programową współpracę z Codesign nie jest kwestią używania loginu lub breloczków systemowych ani modlenia się do jakiegoś boga coding. Musisz tylko mieć ustawione odpowiednie uprawnienia. Polecam stworzenie nowego pęku kluczy specjalnie do celów związanych z kodowaniem.

W dzisiejszych czasach, aby codesignnie uzyskać wyników errSecInternalComponent, musisz uzyskać poprawną listę partycji (ACL). Przejdę przez kolejne kroki:

Utwórz pęku kluczy

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

w tym momencie pęku kluczy jest odblokowany, ale nie pojawi się w Keychain Access.

Dodaj nowy pęku kluczy do listy wyszukiwania

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

Dodaj nowy pęku kluczy do listy. Jeśli najpierw nie pobierzesz oryginalnej listy, list-keychainsktórej nie będzie już login.keychainna Twojej liście wyszukiwania.

Odblokuj pęku kluczy

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

Jest to zbędne, jeśli utworzyłeś pęku kluczy powyżej, ale jeśli pęku kluczy już istniał, jest to konieczne.

Usuń wartości domyślne z pęku kluczy

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

Nie określając żadnych argumentów, ustawi to limit czasu automatycznej blokady na nieograniczony i usunie automatyczną blokadę w stanie uśpienia.

Zaimportuj swoje certyfikaty do podpisywania z pliku .p12

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

Zaimportuj certyfikaty i daj codesigndostęp za pomocą -Topcji.

Ustaw listę ACL w pęku kluczy

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

Jest to wymóg, który brakuje wielu osobom. Możesz zobaczyć, co robi macOS, używając dump-keychain. Co w przypadku kodowania wymaga apple:i apple-tool:. -sodnosi się do podpisywania certyfikatów.

Gitlab-Runner, Jenkins i tym podobne

Jedną bardzo ważną rzeczą dla każdego runnera typu CI lub systemu kompilacji jest upewnienie się, że proces został uruchomiony launchdprawidłowo. Upewnij się, że plist zawiera <SessionCreate> </true>.

Nieprawidłowe dopasowanie właściciela pęku kluczy do procesu budowania i upewnienie się, że sesja bezpieczeństwa została utworzona, spowoduje różnego rodzaju bóle głowy. Z punktu widzenia diagnostyki możesz wprowadzić list-keychainsi sprawdzić, czy wynik spełnia Twoje oczekiwania.

To jest ze strony launchd.plistman:

SessionCreate <boolean>

Ten klucz określa, że ​​zadanie powinno zostać uruchomione w nowej sesji inspekcji bezpieczeństwa, a nie w domyślnej sesji dla kontekstu, do której należy. Szczegóły w auditon (2).

UserName <string>

Ten opcjonalny klucz określa użytkownika, jako którego ma być uruchamiane zadanie. Ten klucz ma zastosowanie tylko do usług, które są ładowane do uprzywilejowanej domeny systemu.

GroupName <string>

Ten opcjonalny klucz określa grupę, w której ma zostać uruchomione zadanie. Ten klucz ma zastosowanie tylko do usług, które są ładowane do uprzywilejowanej domeny systemu. Jeśli ustawiona jest nazwa użytkownika, a nazwa grupy nie jest ustawiona, grupa zostanie ustawiona jako podstawowa grupa użytkownika.

Wreszcie kodowanie

Możesz wyszukać skrót certyfikatów podpisywania za pomocą find-identity

security find-identity -p codesigning -v

Codesign a framework, dylib itp.

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

Zaprojektuj pakiet aplikacji

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

Uwagi końcowe - jeśli spojrzysz na to, jak robi to Xcode, ustawili oni CODESIGN_ALLOCATEna używanie tego zawartego w Xcode, a nie w /usr/bin.

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

Ustawiono ścieżkę wyszukiwania ${PLATFORM_PATH}:${TOOLCHAIN_PATH}:${PATH}, gdzie ścieżka PLATFORMY to katalog / usr / bin dla danego docelowego SDK, a TOOLCHAIN_PATH to / usr / bin dla narzędzi hosta Xcode.

Umieść klucze w pęku kluczy System

Więc to jest polecenie, które działa. -Ama zapobiec pytaniu o hasło przez Maca. Importowanie do system.keychain nie wymaga GUI.

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

Mój pęku kluczy był zablokowany. To opór moje postępy, aby zmienić ten fakt ...

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

Odblokowanie pęku kluczy nie wystarczy. Musisz także ustawić dostęp klucza prywatnego na „Zezwalaj wszystkim aplikacjom na dostęp do tego elementu”. Aby to zrobić z wiersza poleceń, konieczne jest ponowne zaimportowanie klucza. A więc biorąc rzeczy naraz:

Odblokuj pęku kluczy logowania, jeśli jest zablokowany. Nie powinno być jednak blokowane, ale tak czy inaczej, oto jak to zrobić:

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

Jeśli z jakiegoś powodu twoja maszyna budująca ma zablokowany pęku kluczy logowania i nie chcesz ujawniać tego hasła w skrypcie, powinieneś użyć innego pęku kluczy. Możesz go utworzyć na miejscu i użyć go w poprzednim i następnym poleceniu. Aby utworzyć na miejscu:

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

Następnie zaimportuj swoje certyfikaty i powiązane klucze prywatne do pęku kluczy logowania przy użyciu parametru -A. Zauważ, że nie musisz robić tego wszystkiego sudo ...

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

Parametr -A spowoduje ustawienie klucza prywatnego na „Zezwalaj wszystkim aplikacjom na dostęp do tego elementu”

Korzystając z tych wszystkich, powinieneś być w stanie stworzyć skrypt, który zainstaluje wymagany certyfikat w celu zbudowania wydania ipa i podpisania go bez pytania. Możesz przechowywać plik .p12 w swoim repozytorium, dzięki czemu każdy komputer może zbudować Twój IPA bez konieczności ręcznej konfiguracji.

Oprócz odblokowania pęku kluczy (jak wspomniano w innych odpowiedziach), musisz zezwolić wszystkim aplikacjom na dostęp do tokena uwierzytelniania Xcode w pęku kluczy:

• Wybierz pęku kluczy „logowanie”
• Wybierz kategorię „Wszystkie elementy”
• Wyszukaj słowo kluczowe „xcode”
• Wybierz opcję „Zezwalaj wszystkim aplikacjom na dostęp do tego elementu” dla wszystkich tokenów Xcode
• Nie zapomnij dodać kroku odblokowania pęku kluczy (z poprzednich odpowiedzi)

Zaimportuj klucze do pęku kluczy systemu. Możesz użyć tego polecenia:

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

Spróbowałem więc tutaj każdej odpowiedzi i coś się nie zgadzało. W końcu zorientowałem się, że po ponownym uruchomieniu mojej usługi CI działa ona pod innym użytkownikiem, niż się spodziewałem. Zmiana na użytkownika, który faktycznie miał dostęp do klucza w łańcuchu logowania, naprawiła wszystko. Może to nie jest częsty problem, ale chciałem udokumentować mój konkretny powód tego błędu, na wypadek, gdyby zdarzyło się to innym.

Wydaje mi się, że nic nie działało, trzeba ponownie zainstalować Xcode. Jenkins ciągle podaje ten sam błąd. Zaoszczędzisz dużo czasu, jeśli po prostu przeniesiesz instalację Xcode do Kosza i przeinstalujesz. Upewnij się, że uruchomiłeś polecenie Codesign z wiersza poleceń przynajmniej raz.

Nawet jeśli pojawi się ten sam błąd, spróbuj ustawić „Odblokować pęku kluczy?” w Jenkins i podaj ścieżkę do swojego loginu.keychain w /Users/${USER}/Library/Keychains/login.keychain

Mam nadzieję, że Bóg będzie z tobą po tym.

W moim przypadku było to spowodowane tworzeniem pęku kluczy z domyślnym limitem czasu wynoszącym 300 sekund i długą kompilacją xcode trwającą ponad 300 sekund. Dla mnie obejściem było wywołanie:

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

natychmiast po utworzeniu tymczasowego pęku kluczy.

Przejrzałem wszystkie te sugestie i nadal miałem problemy z korzystaniem z Fastlane gym w pracy w . Po zainstalowaniu certyfikatu i odblokowaniu pęku kluczy byłem w stanie podpisać kod na urządzeniu podrzędnym, gdy ręcznie uruchomiłem polecenie Codesign w wierszu poleceń.

W ramach obejścia problemu, jeśli Jenkins łączy się z serwerem slave za pomocą JNLP zamiast SSH, będziesz mógł kodować.

U mnie dzieje się tak, gdy jest dodany ręcznie drugi brelok i jest zablokowany. Z jakiegoś powodu codesignpróbuje uzyskać dostęp do zablokowanego pęku kluczy i kończy się niepowodzeniem, mimo że certyfikaty znajdują się w pęku kluczy logowania (i są odblokowane). Odblokowanie drugiego rozwiązuje problem. Po prostu nie ma to dla mnie sensu.

Po wypróbowaniu kilku z powyższych rozwiązań. Zdałem sobie sprawę, że jednym z czynników było to, że zaczynałem kompilację przy użyciu konsoli ION. Kiedy wróciłem do tworzenia kompilacji z aplikacji Terminal, wszystko działało dobrze.