„Niedozwolona jest interakcja użytkownika” przy próbie podpisania aplikacji OSX za pomocą codeign

145

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”?

Trejkaz
źródło
Jak ustawić hasło pęku kluczy w Circleci?
Sachin Kumaram
@SachinKumaram brzmi jak nowe, realne pytanie?
Trejkaz

Odpowiedzi:

205

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”.

karta kontroli dostępu

bmauter
źródło
2
Nie ma za co. Możesz także rozważyć dodanie kodu code do listy aplikacji na dole zamiast zezwalania na wszystkie aplikacje, tak jak ja. To już jest na moim zrzucie ekranu, ale myślę, że pierwotnie tak nie było.
bmauter,
3
Musiałem odkryć katalog / usr za pomocą apple.stackexchange.com/a/34872/6052, aby móc dodać go codesigndo listy „Zawsze zezwalaj”.
Heath Borders
24
tylko uwaga, że oprócz tego musisz też zrobić security unlock-keychainwszystko
cwd
13
Ponadto możesz chcieć przenieść klucze z logowania do systemu, aby były dostępne podczas zdalnych kompilacji na komputerze.
Krystian
8
Czy ktoś wie, jak to zrobić z wiersza poleceń? Mój komputer do zdalnej kompilacji nie pozwala mi tego robić przy współużytkowaniu ekranu ze względów bezpieczeństwa .
devios1
78

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"
Trejkaz
źródło
17
Dzięki. Udało mi się to zawęzić. Po prostu uruchom następującą komendę tuż przed rozpoczęciem budowania: security -v unlock-keychain -p "$ KEYCHAIN_PASSWORD" "$ HOME / Library / Keychains / login.keychain"
pir800
3
Więc nie ma sposobu, aby uzyskać dostęp codesignprzez ssh bez faktycznego przechowywania hasła logowania w jakimś skrypcie?
chakrit
2
@chakrit w powyższym przykładzie przekazuję tylko hasło pęku kluczy, a nie hasło logowania. Zdaję sobie sprawę, że dla wielu użytkowników pęku kluczy logowania jest jedynym pękiem kluczy, ale w naszym przypadku klucze podpisywania przechowujemy w oddzielnym magazynie kluczy, aby ułatwić ich synchronizację w celu zbudowania maszyn. Ale tak, wiele z tych rzeczy wydaje się raczej niewygodnych w przypadku automatycznych kompilacji, co prowadzi mnie do zastanowienia się, czy Apple w ogóle robi automatyczne kompilacje.
Trejkaz
@Trejkaz oh okay, przynajmniej udostępnianie hasła pęku kluczy nie jest takie złe.
chakrit
W moim przypadku zautomatyzowanych zdalnych kompilacji przechowywanie hasła pęku kluczy do .envpliku nie jest takie złe, ponieważ .envplik zawiera już wrażliwe klucze np. AWS i Heroku. W naszym przypadku poświadczenia znaku kodu związanego z kompilacją są przechowywane w nowo utworzonym pęku kluczy, który jest następnie usuwany po kompilacji. Następnie jest ponownie tworzony na potrzeby następnej kompilacji. Jednak loginpęku kluczy nadal trzeba otworzyć, podobnie security unlock-keychain -p pass login.keychainjak brakujące ogniwo. Dzięki!
Petrus Repo
19

Ż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
yonix
źródło
2
W El Capitan możesz to zrobić również za pośrednictwem interfejsu użytkownika. Po prostu otwórz aplikację pęku kluczy, kliknij prawym przyciskiem myszy swój pęk kluczy (login, system itp.) I kliknij coś, co najlepiej pasuje do opcji „Zmień ustawienia <your_keychain>”.
rubybeginner
Powoduje to zawsze przywrócenie dostępu do pęku kluczy systemu, Confirmnawet po zmianie dostępu. : /
Alex Zavatone
To było dla mnie pomocne!
Nori,
Walczę z tym przez 2 dni, zanim znalazłem twój komentarz, dzięki !!!
Gilad Novik
16

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>
ZhekaKozlov
źródło
4
To to samo, co robienie tego na dwóch liniach. Myślę, że różnica polega na tym, że jeśli pierwsze polecenie zawiedzie, drugie nie uruchomi.
Trejkaz
1
Dla mnie to nie to samo. Dzwonię do nich przez ant sshexeci za każdym razem tworzy nową sesję ssh.
ZhekaKozlov
2
Jeśli naprawdę chcesz, możesz wykonać więcej niż jedną linię w ramach jednej sesji ssh. Więc ... to wciąż to samo, poza traktowaniem błędów.
Trejkaz
13

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.

Cameron Lowell Palmer
źródło
3
Koleś, możesz definitywnie napisać o tym artykuł, szukałem tego od 2 dni. Nie wiem, ile rzeczy i postów dotyczących stackoverflow przeczytałem. Wielkie dzięki !
Damien
Dzięki za tę pomocną instrukcję!
Taras Nikulin
ACL na pęku kluczy była dla mnie brakującą częścią. dziękuję za jasne wyjaśnienie!
Keuha
11

Umieść klucze w pęku kluczy System

Alistra
źródło
Ale nadal pyta o nazwę użytkownika i hasło
Durai Amuthan.H
Jak umieścić klucze w pęku kluczy systemowych ....... skopiuje wklej z dostępu do pęku kluczy?
Ashish Karpe
Przeciągnij i upuść @AshishKarpe
Alistra
Czy funkcja „przeciągnij i upuść” nadal pojawia się ten sam błąd: === BUDUJ DOCELOWY Portal pacjenta PROJEKTU PatientPortal Z KONFIGURACJĄ Debug === Sprawdź zależności Nie znaleziono profili dla „com.abc.xyz360”: Xcode nie mógł znaleźć profilu aprowizacji pasującego do „com .abc.xyz360 ”. Podpisywanie kodu jest wymagane dla typu produktu „Aplikacja” w SDK „iOS 10.2”
Ashish Karpe
Mówi się, że nie masz zainstalowanego profilu obsługi administracyjnej na komputerze, nie oznacza to, że brakuje Ci kluczy @AshishKarpe
Alistra,
5

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

Merlin Ran
źródło
3

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á !

Alex Gray
źródło
2

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.

Radu Simionescu
źródło
2

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)

Zrzut ekranu

Vitaliy Gozhenko
źródło
1

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
Łukasz Czerwinski
źródło
1

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.

Kevin DiTraglia
źródło
Miałem dokładnie ten sam problem. Dziękuję za Twoją odpowiedź. :)
Paweł K
0

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.

Kaushik Bhatt
źródło
0

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.

Justin Randall
źródło
0

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ć.

Dan Stark
źródło
0

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.

Maxime Viargues
źródło
-1

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.

Sean Eisenheim
źródło