Polecenie Xcode / usr / bin / codeign nie powiodło się z kodem zakończenia 1: errSecInternalComponent

105

Próbuję dodać nowy profil obsługi administracyjnej do mojego Xcode, aby przetestować aplikację na urządzeniu. Oto kroki, które wykonałem:

  1. Usunięto wszystkie certyfikaty i profile obsługi

  2. Utwórz / dodaj certyfikat dewelopera IOS

  3. Dodaj moje urządzenie IOS w trybie online

  4. Utwórz profil obsługi administracyjnej systemu IOS

  5. Dodaj profil obsługi administracyjnej systemu IOS

  6. Czysta aplikacja

  7. Zbuduj, a następnie uruchom aplikację

  8. Ustaw Codesigning i Provisioning Profile w Build Settings

  9. Dużo Googlowania> bez sukcesów

Oto błąd, który otrzymuję:

CSSM_SignData returned: 800108E6
/Users/alexpelletier/Library/Developer/Xcode/DerivedData/MyExpense-efnqzvoqwngzcmazaotyalepiice/Build/Products/Debug-iphoneos/MyExpense.app:     errSecInternalComponent
Command /usr/bin/codesign failed with exit code 1
Alex Pelletier
źródło
1
Błąd pochodzi z niezgodności konfiguracji profilu aprowizacji oraz certyfikatów i identyfikatora pakietu. Upewnij się, że Twój PP, identyfikator pakietu i certyfikaty są poprawnie skonfigurowane w i przypisane w itunes connect oraz w aplikacji.
Alex Pelletier
1
Napotkałem ten problem przechodząc z Xcode 11.2.1 do 11.3 podczas podpisywania kodu zbudowanych przeze mnie frameworków. Nie zaangażowano żadnych profili obsługi. Odpowiedź Mohita Manhasa wyjaśniła sprawę.
Daniel Zhang
Dzieje się tak, jeśli używasz SSH i Codesign nie ma dostępu do klucza prywatnego w Keychain. Aby to sprawdzić, znajdź klucz w pęku kluczy, kliknij prawym przyciskiem myszy i wybierz „Uzyskaj informacje”, przełącz na „Kontrola dostępu” i zobacz, czy aplikacja „Codesign” znajduje się na liście „Zawsze zezwalaj na dostęp”. Zobacz ten komentarz github.com/electron-userland/electron-builder/issues/… To, co zrobiłem, to raz uruchomiłem skrypty z GUI i kliknąłem „Zawsze zezwalaj” na dostęp do klucza, a potem zaczęło działać.
ArticIceJuice

Odpowiedzi:

241

Otwórz Dostęp do pęku kluczy , a następnie w menu Plik wybierz Zablokuj wszystkie pęki kluczy .

Następnie wróć do Xcode, wyczyść i odbuduj. Poprosi Cię o ponowne podanie hasła w celu odblokowania pęku kluczy.

Po tym, zakładając, że nie masz innych problemów z kompilacją, to się powiedzie!

Mohit Manhas
źródło
7
Niewiarygodne, że ta głupia blokada i odblokowanie pomaga! Dzięki
Josip B.
8
To powinna być akceptowana odpowiedź. O wiele bardziej rozsądne niż ponowne uruchomienie!
yonix
3
Dla mnie też zadziałało. Zbuduj apk na Androida w 30 sekund, stwórz aplikację na iOS. 2 godz.
Gabe
1
Poważnie WTF ?! Dzięki!
Peter N Lewis,
1
@FredericP Dla mnie niedawno zmieniłem hasło. Wystąpiła więc pewna zależność między ostatnim odblokowaniem pęku kluczy przez xcode a używanym do tego hasłem.
sherrellbc
77

Wygląda na to, że błąd w mechanizmie podpisywania kodu, ponowne uruchomienie komputera Mac powinno rozwiązać problem

sigabrt
źródło
inny przypadek, ale podobny komunikat o błędzie - restart działał.
mikus
Prawie cztery lata później i nadal działa! Zapomniałem złotej zasady - „W razie wątpliwości uruchom ponownie!”
Alan
2
Jeśli czekasz na mniej destrukcyjne rozwiązanie, zobacz odpowiedź
Mohita Manhasa
nie pomogło mi
Anoop Vaidya
70

Dzieje się tak, gdy pęk kluczy logowania jest zablokowany. Aby odblokować pęku kluczy logowania, uruchom:

security unlock-keychain login.keychain

Jeśli Twój pęk kluczy jest chroniony hasłem, podaj hasło za pomocą -popcji.

Następnie spróbuj ponownie wykonać operację kompilacji lub podpisywania kodu. Kod błędu, o którym mowa, jest opisany w dokumentach Apple jako błąd wewnętrzny, więc jest całkiem możliwe, że zdarza się to również w innych przypadkach.

cbracken
źródło
1
Niestety to rozwiązanie wydaje się całkowicie okrągłe: uruchomienie powyższego polecenia wymaga podania hasła, co jest oczywiście niedopuszczalne w sesji nieinteraktywnej (na przykład podczas wykonywania tego za pośrednictwem agenta CI, takiego jak Jenkins).
Konrad Rudolph
To dobra uwaga - jak mówisz, nie jest to odpowiednie dla sesji nieinteraktywnych, takich jak bot CI. Jest to przydatne podczas uruchamiania zdalnych kompilacji w sesji wiersza poleceń (np. Przez ssh).
cbracken
3
Mieliśmy podobny problem na Jenkinsie i oprócz tego, co jest wspomniane w powyższym poleceniu, musieliśmy przekazać hasło jako argument do polecenia, więc zrobiliśmy "security unlock-keychain -p $ KeychainPassword <login-keychain>", gdzie możesz łatwo i bezpiecznie przechowywać KeychainPaasword na Jenkins.
Mohit Tater
1
Nie mogę ci wystarczająco podziękować za ten post. Spędziłem kilka dni próbując dowiedzieć się, dlaczego się codesignnie udało i to jest magiczne polecenie, które mnie uratowało !!!
Dimu4
32

Gdy ten sam problem pojawił się w High Sierra/ Xcode 9.4.1, wszystkie próby zalogowania się zakończyłyerrSecInternalComponent

    • Przejdź do Dostęp do pęku kluczy
    • Przejdź do pęku kluczy logowania
    • Wybierz kategorię „Moje certyfikaty”
    • Znajdź certyfikat, którym się podpisujesz, i rozwiń go, aby wyświetlić klucz.
    • Kliknij dwukrotnie klucz
    • Przejdź do zakładki „Kontrola dostępu”.
    • Zaktualizuj kontrolę dostępu do klucza na „Zezwalaj wszystkim aplikacjom na dostęp do tego elementu”

Alternatywnie:

uruchom polecenie Codesign na terminalu Mac i „Zawsze zezwalaj” / usr / bin / Codesign na dostęp do klucza

  1. Jeśli próbujesz podpisać z ssh / CI, musisz również uruchomić

    security unlock-keychain login.keychain

    przed próbą podpisania pakietu aplikacji

równowaga
źródło
Czy możesz rozwinąć temat „zaktualizuj kontrolę dostępu klucza do„ Zezwalaj wszystkim aplikacjom na dostęp do tego elementu ”? Nie mam pojęcia, co to w ogóle oznacza.
Jon McClung
2
@JonMcClung Otwórz dostęp do pęku kluczy, przejdź do pęku kluczy logowania - moje certyfikaty. Znajdź certyfikat, którym podpisujesz, rozwiń go, aby zobaczyć klucz. Kliknij dwukrotnie klawisz i powinieneś zobaczyć zakładkę „Kontrola dostępu”. Przełącz, aby zezwolić
Equilibrium
5
@KonradRudolph security unlock-keychain -p <password> login.keychainz CI.
Równowaga
1
@KonradRudolph nie jest konieczne podawanie hasła do odblokowania pęku kluczy, jeśli zezwoliłeś kodowaniu na dostęp do klucza prywatnego. Wystarczy zostawić pusty ciąg jako hasło.
Kamil Szostakowski
1
@KonradRudolph nadal prawdopodobnie nie jest idealny, ale możesz przenieść to polecenie odblokowania na ~/.bash_profiletak, aby pęku kluczy odblokowywał się podczas uruchamiania klienta SSH, ale nie potrzebujesz odniesienia do niego ze skryptu CI
sschilli
17

Spotkałem ten sam problem, ponownie uruchamiam macOS i działa.

W Chinach mamy powiedzenie między programistami:

Małe problemy, po prostu uruchom ponownie. Duże problemy powinny zostać ponownie zainstalowane.

Czasami powyższe powiedzenie bardzo ci pomoże!

ifeegoo
źródło
7
W Ameryce mówimy - „Nigdy nie uruchamiaj ponownie starego sprzętu”
Brant
@Brant Dlaczego masz to powiedzenie? To interesujące.
ifeegoo
Żartuję - ale mieliśmy podobny problem iw końcu po prostu uciekliśmy się do ponownego uruchomienia starego serwera.
Brant
1
@ifeegoo Stare serwery mogą mieć problemy z uruchomieniem kopii zapasowej (może system operacyjny sam się zaktualizował? może ktoś zepsuł skrypty startowe?) lub wymagają ręcznej procedury uruchamiania, o której nikt nie wie. Nie możesz wiedzieć, zanim spróbujesz. Może bios zepsuł się. To tylko jedna z tych rzeczy, które nie powinny stanowić problemu w odpowiednio utrzymanym środowisku, ale tak naprawdę nie wiesz, zanim spróbujesz i wolisz nie próbować.
Lassi Kinnunen,
1
@LassiKinnunen Masz rację, jesteśmy programistami mobilnymi na Androida i iOS, więc taka sytuacja nie dba o serwery, serwery są naprawdę niebezpieczne, nie da się ich zlokalizować.
ifeegoo
8

Na wypadek, gdyby pomogło to komuś innemu, napotkałem errSecInternalComponentbłąd, codesignponieważ uruchamiałem go podczas sesji ssh na moim komputerze z systemem macOS. Uruchomienie tego samego polecenia z okna terminala na komputerze z systemem macOS działało.

Prawdopodobnie dzieje się tak, ponieważ codesignwymaga dostępu do klucza prywatnego z pęku kluczy logowania.

Uruchomienie security unlock-keychain login.keychain(jak wyjaśnia odpowiedź cbrackena ) z tej samej sesji również powinno działać.

jamesdlin
źródło
Jest to bardzo dziwne, nawet uruchomienie polecenia odblokowania pęku kluczy wydaje się po cichu nie powieść, ponieważ kod nadal nie działa. Ale uruchamianie tych samych poleceń za pomocą zdalnego pulpitu (zamiast SSH) działa dobrze.
Max
2

Jeśli próbujesz podpisać polecenie ssh run:

security unlock-keychain login.keychain

przed próbą podpisania pakietu aplikacji

lub z interfejsu użytkownika

Zaktualizuj kontrolę dostępu do klucza na „Zezwalaj wszystkim aplikacjom na dostęp do tego elementu”

Podziękowania dla @Equilibrium i @Jon McClung

Stas S.
źródło
2

Miałem ten sam problem. Okazało się, że problem dotyczy podpisywania kodu aplikacji.

Opened the developer account and accepted the updated agreement and it worked.  

wprowadź opis obrazu tutaj

sahiljain
źródło
2

Pobiegłem security unlock-keychain login.keychaini moje hasło logowania nie działa. Więc zrestartowałem, a potem po prostu ponownie uruchomiłem Xcode i zadziałało. Uruchomienie polecenia również działa. Dziwny problem.

sunapi386
źródło
2

Jak wskazał @Equilibrium w jednym z komentarzy, jeśli jesteś w wierszu poleceń env. podobnie jak Jenkins (mój przypadek), może być konieczne przekazanie hasła do polecenia odblokowania zabezpieczeń wspomnianego w rozwiązaniach.

Więc zamiast używać,

security unlock-keychain login.keychain

posługiwać się:

security unlock-keychain -p <login-keychain-password> <path-to-login-keychain>

gdzie pęku kluczy ścieżka do logowania może być $ HOME / Library / Keychains / login.keychain (mój przypadek) lub po prostu login.keychain

Mohit Tater
źródło
Twoja odpowiedź jest oparta na odpowiedzi @equilibrium, ale ja to wymyślę. W Bamboo CI pomogłem wydać
A.Kant
2

dla każdego, kto napotkał ten problem z jenkins i ssh:

duże prawdopodobieństwo, że nie przyznałeś dostępu do klucza prywatnego w pęku kluczy. Próbowałem, ale nie jestem pewien, dlaczego wszystkie one nie działają:

  1. plik importu bezpieczeństwa .p12 z -A lub -T / usr / bin / codign
  2. zestaw-kluczy-lista-partycji -S apple-tool:, apple:, codeign: -s -k # {hasło} # {ścieżka-pęku kluczy}
  3. zmień wszystkie profile aprowizacji na [UUID] .mobileprovision i skopiuj je do „~ / Library / MobileDevice / Provisioning \ Profiles” na serwerze Jenkins
  4. wyczyść dane pochodne i zrestartuj serwer jenkins
  5. upewnij się, że domyślnym pękiem kluczy jest pęk kluczy logowania i odblokowałeś go.

ostatecznie rozwiązany przez:

1.ssh [użytkownik] @ [jenkinsServerIP] -L 5900: localhost: 5900, zaloguj się do serwera jenkins

2. open „vnc: // localhost”

to uruchomi zdalny ekran, jeśli twój serwer jenkins pozwala na to ...

następnie otwórz keychain.app, aby przyznać dostęp do / usr / bin / codsign do klucza prywatnego

powodzenia

Xi Zhang
źródło
1

Po prostu spróbuj raz, używając terminala Mac, ale nie z sesji ssh

security unlock-keychain login.keychain

I wybierz zawsze zezwalaj w wyświetlonym oknie dialogowym. A potem możesz xcodebuild w sesji zdalnej.

Felix
źródło
1

Kliknięcie prawym przyciskiem myszy na klucz prywatny powiązany z certyfikatem do kodowania w pęku kluczy, a następnie kliknięcie „zezwól na wszystkie aplikacje” zamiast polegania na monicie, naprawiło to za mnie, ponieważ kompilacja odbywała się za pośrednictwem ssh.

Śrut
źródło
0

Musiałem:

1) usuń certyfikat powiązany z projektem

2) Wróć do Xcode i unieważnij certyfikat aplikacji

3) Xcode wymaga nowego certyfikatu

4) Zablokuj wszystkie KeyChain

5) Wyczyść projekt

6) Odbuduj

Otóż ​​to. Mam nadzieję, że to pomoże każdemu.

Andres Felipe
źródło
0

Powyższe metody są dla mnie bezużyteczne.

Rozwiązałem to przez:

  1. Otwórz dostęp do pęku kluczy.
  2. Kliknij menu logowania.
  3. Usuń wszystkie certyfikaty osobiste.
  4. Wyczyść projekt.
  5. Odbudować.

Otóż ​​to. Mam nadzieję, że to pomoże każdemu.

yerwoo_gmail
źródło