Jenkins na OS X: xcodebuild wyświetla błąd Code Sign

Podsumowanie:

Konfiguracja Jenkinsa na OS X została znacznie ułatwiona dzięki najnowszemu instalatorowi ( od 1.449 - 9 marca 2012 ), jednak zarządzanie procesem podpisywania kodu jest nadal bardzo trudne i nie ma prostej odpowiedzi.

Motywacja:

Uruchom bezgłowy serwer CI, który postępuje zgodnie z najlepszymi praktykami dotyczącymi uruchamiania usług w systemie OS X ( niektóre z nich wyjaśniono tutaj w prostym języku ).

Tło:

• 12 października 2009 - Jak zautomatyzować kompilacje aplikacji na iPhone'a za pomocą Hudson
• 15 czerwca 2011 r. - Jenkins w systemie Mac OS X; git w / ssh klucz publiczny
• 23 czerwca 2011 r. - ciągłe wdrażanie aplikacji iOS z Jenkins i TestFlight
• 26 lipca 2011 - Brakujące certyfikaty i klucze w pęku kluczy podczas używania Jenkins / Hudson jako ciągłej integracji dla rozwoju iOS i Mac
• 30 sierpnia 2011 - Nie znaleziono pliku obsługi Xcode w Jenkins
• 20 września 2011 r. - Jak skonfigurować Jenkins CI na komputerze Mac
• 14 września 2011 r. - Uruchomienie Jenkinsa na komputerze Mac
• 12 listopada 2011 - Howto: Zainstaluj Jenkins w systemie OS X i spraw, by kompilował elementy Mac
• 23 stycznia 2012 - Nadchodzące zmiany w instalatorze Jenkins OSX
• 7 marca 2012 - Dziękujemy za skorzystanie z instalatora OSX

Proces:

Jenkins CI zainstalować OS X za pomocą pakietu instalacyjnego . W kroku „Typ instalacji” kliknij przycisk Dostosuj i wybierz opcję „Rozpocznij podczas rozruchu jako 'jenkins'”.

Dyskusja:

W tym momencie naiwnym oczekiwaniem było, że projekt w wolnym stylu ze skryptem kompilacji xcodebuild -target MyTarget -sdk iphoneospowinien działać. Jak wskazuje tytuł tego posta, nie kończy się on i zawodzi z:

Code Sign error: The identity 'iPhone Developer' doesn't match any valid certificate/private key pair in the default keychain

Jest oczywiste, co musi się stać - do domyślnego pęku kluczy należy dodać ważny certyfikat podpisujący kod i klucz prywatny. Badając, jak to osiągnąć, nie znalazłem rozwiązania, które nie otwiera systemu na pewien poziom podatności.

Problem 1: Brak domyślnego pęku kluczy dla demona jenkinsa

sudo -u jenkins security default-keychain ... daje komunikat „Nie można znaleźć domyślnego pęku kluczy”

Jak wskazał poniżej Ivo Dancet , powłoka użytkownika jest domyślnie ustawiona na / usr / bin / false dla demona jenkinsa (myślę, że jest to funkcja, a nie błąd); postępuj zgodnie z jego odpowiedzią, aby zmienić UserShell na bash. Następnie sudo su jenkinsmożesz zalogować się jako użytkownik jenkins i uzyskać monit bash.

1. sudo su jenkins
2. cd ~/Library
3. mkdir Keychains
4. cd Keychains
5. security create-keychain <keychain-name>.keychain
6. security default-keychain -s <keychain-name>.keychain

Okej świetnie. Mamy teraz domyślny pęku kluczy; przejdźmy dalej, prawda? Ale po pierwsze, dlaczego w ogóle zawracaliśmy sobie głowę tworzeniem domyślnego pęku kluczy?

Prawie wszystkie odpowiedzi, sugestie lub rozmowy, które czytałem podczas badań, sugerują, że należy po prostu wrzucić ich certyfikaty i klucze do podpisywania kodu do pęku kluczy systemu. Jeśli uruchomisz security list-keychainsprojekt w stylu swobodnym w Jenkins, zobaczysz, że jedynym dostępnym pękiem kluczy jest pęk kluczy systemowych; Myślę, że właśnie tam większość ludzi wpadła na pomysł, aby umieścić tam swój certyfikat i klucz. Ale wydaje się to po prostu bardzo złym pomysłem - zwłaszcza biorąc pod uwagę, że będziesz musiał utworzyć zwykły skrypt tekstowy z hasłem do otwarcia pęku kluczy .

Problem 2: Dodawanie certyfikatów do podpisywania kodu i klucza prywatnego

To jest, gdy naprawdę zaczynam być wrażliwy. Mam przeczucie, że powinienem utworzyć nowy klucz publiczny / prywatny, unikalny do użytku z Jenkinsem. Myślę, że jeśli demon Jenkins zostanie przejęty, mogę łatwo odwołać certyfikat w portalu obsługi administracyjnej Apple i wygenerować inny klucz publiczny / prywatny. Jeśli używam tego samego klucza i certyfikatu dla mojego konta użytkownika i Jenkinsa, oznacza to więcej kłopotów (uszkodzeń?), Jeśli usługa Jenkins zostanie zaatakowana.

Wskazując na odpowiedź Simona Urbanka, odblokujesz pęku kluczy ze skryptu z hasłem w postaci zwykłego tekstu. Przechowywanie czegokolwiek poza „jednorazowymi” certyfikatami i kluczami w pęku kluczy demona Jenkinsa wydaje się nieodpowiedzialne.

Jestem bardzo zainteresowany każdą dyskusją o czymś przeciwnym. Czy jestem zbyt ostrożny?

Aby utworzyć nowy CSR jako demon Jenkinsa w Terminalu, wykonałem następujące czynności ...

1. sudo su jenkins
2. certtool r CertificateSigningRequest.certSigningRequest Zostaniesz poproszony o podanie następujących informacji (w większości z nich zgadłem prawidłową odpowiedź; czy masz lepszy wgląd? Udostępnij) ...
   • Wpisz klucz i etykietę certyfikatu:
   • Wybierz algorytm: r(dla RSA)
   • Wprowadź rozmiar klucza w bitach: 2048
   • Wybierz algorytm podpisu: 5(dla MD5)
   • Wpisz ciąg wyzwania:
   • Następnie kilka pytań do RDN
3. Prześlij wygenerowany plik CSR (CertificateSigningRequest.certSigningRequest) do portalu Apple Provisioning Portal pod nowym identyfikatorem Apple ID
4. Zatwierdź żądanie i pobierz plik .cer
5. security unlock-keychain
6. security add-certificate ios_development.cer

To przybliża nas o krok ...

Problem 3: Udostępnianie profilu i odblokowywanie pęku kluczy

Utworzyłem specjalny profil obsługi administracyjnej w portalu obsługi administracyjnej tylko do użytku z CI w nadziei, że jeśli wydarzy się coś złego, zmniejszyłem wpływ. Najlepsza praktyka czy zbyt ostrożna?

1. sudo su jenkins
2. mkdir ~/Library/MobileDevice
3. mkdir ~/Library/MobileDevice/Provisioning\ Profiles
4. Przenieś profil informacyjny skonfigurowany w portalu obsługi administracyjnej do tego nowego folderu. Jesteśmy teraz o dwa krótkie kroki od uruchomienia xcodebuild z wiersza poleceń jako jenkins, a to oznacza, że ​​jesteśmy również blisko uzyskania uruchomionych kompilacji Jenkins CI.
5. security unlock-keychain -p <keychain password>
6. xcodebuild -target MyTarget -sdk iphoneos

Teraz otrzymujemy pomyślną kompilację z wiersza poleceń po zalogowaniu się jako demon jenkins, więc jeśli utworzymy projekt w stylu swobodnym i dodamy te dwa ostatnie kroki (# 5 i # 6 powyżej), będziemy mogli zautomatyzować budowanie nasz projekt na iOS!

Może to nie być konieczne, ale po pomyślnym uzyskaniu całej tej konfiguracji poczułem się lepiej ustawiając jenkins UserShell z powrotem na / usr / bin / false. Czy jestem paranoikiem?

Problem 4: Domyślny pęku kluczy nadal nie jest dostępny!

( EDYCJA: opublikowałem zmiany w moim pytaniu, uruchomiłem ponownie, aby upewnić się, że moje rozwiązanie jest w 100% i oczywiście pominąłem krok )

Nawet po wykonaniu wszystkich powyższych czynności musisz zmodyfikować plik plist Launch Daemon w /Library/LaunchDaemons/org.jenkins-ci.plist, jak podano w tej odpowiedzi . Należy pamiętać, że jest to również błąd openrdara .

To powinno wyglądać tak:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>EnvironmentVariables</key>
        <dict>
                <key>JENKINS_HOME</key>
                <string>/Users/Shared/Jenkins/Home</string>
        </dict>
        <key>GroupName</key>
        <string>daemon</string>
        <key>KeepAlive</key>
        <true/>
        <key>Label</key>
        <string>org.jenkins-ci</string>
        <key>ProgramArguments</key>
        <array>
                <string>/bin/bash</string>
                <string>/Library/Application Support/Jenkins/jenkins-runner.sh</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
        <key>UserName</key>
        <string>jenkins</string>
        <!-- **NEW STUFF** -->
        <key>SessionCreate</key>
        <true />
</dict>
</plist>

Przy takiej konfiguracji poleciłbym również wtyczkę Xcode dla Jenkinsa , która sprawia, że ​​konfiguracja skryptu xcodebuild jest trochę łatwiejsza. W tym miejscu polecam również przeczytanie stron podręcznika dla xcodebuild - do diabła, dotarłeś tak daleko w Terminalu, prawda?

Ta konfiguracja nie jest idealna, a wszelkie rady lub spostrzeżenia są bardzo cenne.

Trudno mi było wybrać „poprawną” odpowiedź, ponieważ to, co wykorzystałem do rozwiązania mojego problemu, było zbiorem prawie każdego wkładu. Próbowałem dać każdemu przynajmniej głos za, ale przyznaj odpowiedź Simonowi, ponieważ on głównie odpowiedział na pierwotne pytanie. Co więcej, Sami Tikka zasługuje na duże uznanie za swoje wysiłki, aby Jenkins pracował za pomocą AppleScript jako zwykłej starej aplikacji OS X. Jeśli jesteś zainteresowany tylko uruchomieniem Jenkinsa i szybkim przejściem w ramach sesji użytkownika (tj. Nie jako serwera bezgłowego), jego rozwiązanie jest znacznie bardziej podobne do Maca.

Mam nadzieję, że moje wysiłki wywołają dalszą dyskusję i pomogę następnej biednej duszy, która przyjdzie, myśląc, że może w weekend uzyskać konfigurację Jenkins CI dla swoich projektów iOS ze względu na wszystkie wspaniałe rzeczy, które o tym słyszeli.

Aktualizacja: 9 sierpnia 2013 r

Mając tak wiele pozytywnych głosów i faworytów, pomyślałem, że wrócę do tego 18 miesięcy później i wyciągnę kilka krótkich wniosków.

Lekcja 1: Nie ujawniaj Jenkinsa publicznemu internetowi

Na WWDC 2012 zadałem to pytanie inżynierom Xcode i OS X Server. Otrzymałem kakofonię „nie rób tego!” od każdego, kogo zapytałem. Wszyscy zgodzili się, że zautomatyzowany proces kompilacji był świetny, ale serwer powinien być dostępny tylko w sieci lokalnej. Inżynierowie OS X Server zasugerowali umożliwienie zdalnego dostępu przez VPN.

Lekcja 2: Są teraz nowe opcje instalacji

Niedawno opowiedziałem CocoaHeads o moim doświadczeniu z Jenkinsem i ku mojemu zdziwieniu znalazłem kilka nowych metod instalacji - Homebrew, a nawet wersję Bitnami Mac App Store . Zdecydowanie warto je sprawdzić. Jonathan Wright ma streszczenie opisujące, jak działa Homebrew Jenkins .

Lekcja 3: Nie, poważnie, nie ujawniaj skrzynki kompilacji w Internecie

Z oryginalnego postu jasno wynika, że ​​nie jestem ani administratorem systemu, ani ekspertem ds. Bezpieczeństwa. Zdrowy rozsądek dotyczący rzeczy prywatnych (breloki, dane uwierzytelniające, certyfikaty itp.) Sprawił, że poczułem się dość nieswojo, gdy umieściłem mój Jenkins w Internecie. Nick Arnott z Neglected Potential był w stanie dość łatwo potwierdzić moje heebie-jeebies w tym artykule .

TL; DR

Moja rekomendacja dla innych, którzy chcą zautomatyzować proces kompilacji, zmieniła się w ciągu ostatniego półtora roku. Upewnij się, że maszyna Jenkins jest za zaporą ogniową. Zainstaluj i skonfiguruj Jenkins jako dedykowanego użytkownika Jenkins za pomocą instalatora, wersji Bitnami Mac App Store, AppleScript Sami Tikka itp .; to rozwiązuje większość bólu głowy, który szczegółowo opisałem powyżej. Jeśli potrzebujesz zdalnego dostępu, skonfigurowanie usług VPN w OS X Server zajmuje maksymalnie dziesięć minut. Używam tej konfiguracji od ponad roku i jestem z niej bardzo zadowolony. Powodzenia!

Breloki muszą zostać odblokowane, zanim będą mogły być używane. Możesz użyć security unlock-keychaindo odblokowania. Możesz to zrobić interaktywnie (bezpieczniej) lub podając hasło w linii poleceń (niebezpieczne), np .:

security unlock-keychain -p mySecretPassword...

Oczywiście umieszczenie tego w skrypcie zagraża bezpieczeństwu tego pęku kluczy, więc często ludzie konfigurują indywidualny pęku kluczy tylko z poświadczeniami podpisu, aby zminimalizować takie uszkodzenia.

Zazwyczaj Terminalpęku kluczy jest już odblokowany przez twoją sesję, ponieważ domyślny pęk kluczy jest odblokowywany podczas logowania, więc nie musisz tego robić. Jednak żaden proces, który nie zostanie uruchomiony w Twojej sesji, nie będzie miał odblokowanego pęku kluczy, nawet jeśli ma Ciebie jako użytkownika (najczęściej dotyczy to ssh, ale także każdego innego procesu).

Załóżmy, że chcesz również przeprowadzić dystrybucję ad hoc za pośrednictwem Jenkins, co wymaga, aby Jenkins miał dostęp do certyfikatu dystrybucji i tożsamości administratora zespołu, oprócz profili aprowizacji.

Używając wyeksportowanej tożsamości w pliku .cer, możesz programowo zaimportować ją w ten sposób, przełącznik -A umożliwia wszystkim programom dostęp do tego wpisu. Alternatywnie możesz użyć kilku -T /path/to/programprzełączników, aby zezwolić codesigni xcodebuilduzyskać dostęp:

$ security import devcertificate.cer -k jenkins.keychain -A

Oczywiście powinniśmy mieć również certyfikat Apple WWDCRA, importowany w prawie taki sam sposób:

$ security import AppleWWDRCA.cer -k jenkins.keychain -A

Potrzebujemy jednak również klucza prywatnego dla devcertificate.cer. Aby to zrobić, musisz wyeksportować odpowiedni klucz prywatny jako klucz .p12 i ustawić hasło. Umieść go w miejscu, do którego możesz uzyskać dostęp ze swojej powłoki Jenkins, odblokuj pęku kluczy i zaimportuj go:

$ security unlock-keychain -p YourKeychainPass jenkins.keychain
$ security import devprivatekey.p12 -k login.keychain -P ThePasswordYouSetWhenExporting -A

Importowanie certyfikatu dystrybucyjnego działa w ten sam sposób. Nie wiem, dlaczego musisz odblokować pęku kluczy, aby zaimportować plik .p12, a nie .cer, ale cóż.

Będziesz także potrzebować dostępu do profili obsługi administracyjnej. Wkrótce zmodyfikuję te instrukcje w tym poście.

Miałem ten sam problem i od jakiegoś czasu szukałem odpowiedzi. Oto jedna rzecz, której się nauczyłem.

Używam jenkins jako użytkownik jenkins, użytkownik utworzony przez instalatora i jak wszyscy wspominali, nie ma on dostępu do tego samego pęku kluczy, co zwykły użytkownik. Zamiast próbować zalogować się jako użytkownik jenkins, stworzyłem drugi projekt kompilacji, który ma po prostu jeden krok kompilacji, czyli „Wykonanie powłoki”, w którym uruchamiam polecenia, które chcę przetestować jako użytkownik jenkins.

Gdy już to skonfigurowałem, mogłem uruchomić polecenie

security list-keychains

I to pokazało mi, że jedyną rzeczą, jaką Jenkins mógł zobaczyć, był systemowy brelok.

+ security list-keychains
    "/Library/Keychains/System.keychain"
    "/Library/Keychains/System.keychain"

Mając tę ​​wiedzę, otworzyłem aplikację Dostęp do pęku kluczy i skopiowałem mój certyfikat „iPhone Developer: xxxx” do pęku kluczy systemu (kliknij prawym przyciskiem myszy, skopiuj z pęku kluczy „login”).

To sprawiło, że przeszedłem błąd podpisania kodu pary certyfikatu / klucza prywatnego, ale otworzyłem inny z profilem aprowizacji (wydaje się, że jest to podobny, ale inny problem).

Aby zmienić hasło, możesz użyć sudo passwd jenkins <new-pw>. Jednak myślę, że byłoby lepiej użyć polecenia dscl, aby zmienić hasło.

W mojej instalacji jenkins (oficjalny instalator) miał powłokę użytkownika / usr / bin / false. Zmiana na bash rozwiązała problem braku możliwości zalogowania się:

sudo dscl . -change /Users/jenkins UserShell /usr/bin/false /bin/bash

Powinieneś teraz móc się zalogować za pomocą su jenkins.

Użyłem wtyczki Xcode do zbudowania aplikacji na iOS. W konfiguracji projektu.

wybierz opcję Dodaj krok kompilacji> Xcode> podpisywanie kodu i opcje pęku kluczy OS X.

zaznacz pole Odblokuj pęku kluczy i dodaj w następujący sposób (przykłady)

czasami, jeśli otrzymam błąd

Błąd znaku kodu: ...

Otworzę ponownie Jenkins i ponownie wprowadzę hasło, aby odblokować

Osobom mającym problemy z pękami kluczy polecam wypróbowanie mojego alternatywnego instalatora Jenkinsa na https://github.com/stisti/jenkins-app , pliki do pobrania na https://github.com/stisti/jenkins-app/downloads

Jenkins.app uruchamia Jenkins w sesji użytkownika, więc problemy z dostępem do pęku kluczy nie stanowią problemu :)

Jeśli masz sudo, możesz użyć passwd, aby zmienić hasło użytkownika Jenkins. Następnie możesz uzyskać hasło Jenkins.

Nie jestem też pewien, czy to jest dla ciebie problem, ale skrypt ANT, którego używam przez Jenkins, ma to:

<target name="unlock_keychain">
    <exec executable="security">
        <arg value="-v"/>
        <arg value="unlock-keychain"/>          
        <arg value="-p"/>
        <arg value="<My Password>"/>
        <arg value="/Users/macbuild/Library/Keychains/login.keychain"/>
    </exec>
</target>

Z jakiegoś powodu narzędzie "bezpieczeństwa" nie działało dla mnie w Lionie z nową instalacją Jenkinsa.

Po "sudo su jenkins" był w stanie stworzyć nowy pęku kluczy, ale po cichu ignorował wszystkie polecenia "default-keychain -s ..." lub "unlock" zwracające zerowy status wyjścia i nic nie drukując na konsoli. Wyświetlanie domyślnych lub logowania pęków kluczy nic nie dało, lista wyszukiwania pęków kluczy zawierała tylko pęku kluczy systemowych i nie mogłem tego zmienić, cokolwiek piszę.

Po zalogowaniu się do pulpitu tego użytkownika i uruchomieniu narzędzia Keychain Utility, pokazał mój utworzony pęku kluczy, a potem wszystko działało zgodnie z opisem w górnych postach.

Zastanawiam się, czy niektóre z początkowych zachowań pęków kluczy uległy zmianie w Lion, czy też czegoś mi brakuje?

Dodałem klucz prywatny i publiczny firmy do pęku kluczy. Dodałem profile prowizyjne do produkcji, którą będę budować.

Ponieważ ten użytkownik nie miał konta, zalogowałem się do devcenter za pomocą mojego konta. Pobrano certyfikaty aprowizacji i załadowano je do Xcode.

Nie dodałem certyfikatu specjalnie dla konta roli kompilacji, np. Jenkins.

Dodałem to do skryptu kompilacji: security unlock-keychain -p mySecretPassword jak powyżej, ale ...

Utworzyłem plik ~ / .ssh / mypass i dodałem hasło do pliku.

Następnie polecenie wygląda następująco: bezpieczeństwo odblokowania pęku kluczy -p cat ~/.ssh/mypass

Kompilacje działają jak mistrz. Otrzymuję plik ipa, ładuje się w centrali aplikacji i działa na urządzeniu.

Można również zainstalować i uruchomić JenkinsCI jako użytkownik OS X zamiast demona:

1. zainstaluj jenkins za pomocą oficjalnego instalatora ( https://jenkins-ci.org/ )
   • Kliknij Następny
   • Kliknij „Dostosuj”
   • Odznacz "Start at boot as 'jenkins'" - * WAŻNE * ta opcja normalnie zezwala na bezgłowe jenkins, które nie działają dobrze z dostępem do pęku kluczy
2. Uruchomić http://127.0.0.1:8080
   • sprawdź, czy NIE uruchamia się
   • być może trzeba będzie powstrzymać Jenkinsa sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
3. Podwójne kliknięcie /Applications/Jenkins/jenkins.war
   • oczywiście powinno to być zautomatyzowane, aby rozpocząć @ uruchomienie
4. otwarty http://127.0.0.1:8080
   • sprawdź, czy teraz działa

Aby rozwiązać ten problem, zaloguj się na http://appleid.apple.com i zaktualizuj pytania zabezpieczające.

Pomogło mi.