Вопросы Теги

Jenkins в OS X: xcodebuild выдает ошибку Code Sign

Резюме:

Однако установка Jenkins на OS X значительно упростилась с помощью самого последнего установщика ( с 1.449 - 9 марта 2012 ). управлять процессом подписи кода по-прежнему очень сложно, и однозначного ответа нет.

Мотивация:

Запуск автономного CI-сервера, который следует общепринятым рекомендациям по запуску служб в OS X ( Некоторые из них объясняются здесь простым языком ).

Справочная информация:

Процесс:

Установите Jenkins CI через пакет установщика OS X . Для шага «Тип установки» нажмите кнопку «Настроить» и выберите «Начать при загрузке как 'jenkins'».

Обсуждение:

Наивное ожидание на этом этапе заключалось в том, что проект свободного стиля со сценарием сборки xcodebuild -target MyTarget -sdk iphoneos должен работать. Как указано в заголовке этого сообщения, этого не происходит и происходит сбой:

Ошибка подписи кода: идентификатор «iPhone Developer» не соответствует ни одной действительной паре сертификат / закрытый ключ в цепочке ключей по умолчанию

Это очевидно Достаточно того, что должно произойти - вам нужно добавить действительный сертификат подписи кода и закрытый ключ в цепочку ключей по умолчанию.Исследуя, как это сделать, я не нашел решения, которое не открывало бы систему до некоторого уровня уязвимости.

Проблема 1. Нет связки ключей по умолчанию для демона jenkins

sudo -u jenkins security default-keychain ... дает "Связку ключей по умолчанию не удалось найти"

Как указано ниже Иво Дансет , UserShell по умолчанию установлен в / usr / bin / false для демона jenkins (я думаю это особенность, а не ошибка); следуйте его ответу, чтобы изменить UserShell на bash. Затем вы можете использовать sudo su jenkins , чтобы войти в систему как пользователь jenkins и получить приглашение bash.

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

Хорошо, отлично. Теперь у нас есть связка ключей по умолчанию; пойдем дальше правильно? Но сначала, почему мы вообще потрудились создать связку ключей по умолчанию?

Почти все ответы, предложения или беседы, которые я читал во время исследования, предполагают, что нужно просто забросить их сертификаты подписи кода и ключи в системную связку ключей. Если вы запустите security list-keychains как бесплатный проект в Jenkins, вы увидите, что единственная доступная связка ключей - это системная связка ключей; Думаю, именно здесь большинству людей пришла в голову идея поместить туда свой сертификат и ключ. Но это кажется очень плохой идеей - особенно с учетом того, что вам потребуется создать текстовый скрипт с паролем, чтобы открыть связку ключей .

Проблема 2: Добавление сертификатов подписи кода и закрытого ключа

Здесь я действительно начинаю проявлять брезгливость. У меня интуитивное предчувствие, что я должен создать новый открытый / закрытый ключ, уникальный для использования с Jenkins. Мой мыслительный процесс заключается в том, что если демон jenkins скомпрометирован, я могу легко отозвать сертификат на портале подготовки Apple и сгенерировать другой открытый / закрытый ключ. Если я использую один и тот же ключ и сертификат для своей учетной записи пользователя и Jenkins, это означает больше хлопот (повреждений?), Если служба jenkins будет атакована.

Указывая на ответ Саймона Урбанека , вы разблокируете связку ключей из сценария с паролем в виде простого текста. Кажется безответственным хранить что-либо, кроме «одноразовых» сертификатов и ключей в связке ключей демона jenkins.

Меня очень интересуют любые дискуссии об обратном. Я слишком осторожен?

Чтобы создать новую CSR в качестве демона jenkins в Терминале, я сделал следующее ...

  1. sudo su jenkins
  2. certtool r CertificateSigningRequest.certSigningRequest Вам будет предложено ввести следующие (большинство из них я сделал обоснованные предположения относительно правильного ответа; у вас есть лучшее понимание?Поделись, пожалуйста.)...
    • Введите ключ и метку сертификата:
    • Выберите алгоритм: r (для RSA)
    • Введите размер ключа в битах: 2048
    • Выберите алгоритм подписи: 5 (для MD5)
    • Введите строку запроса:
    • Затем несколько вопросов для RDN
  3. Отправьте сгенерированный файл CSR (CertificateSigningRequest.certSigningRequest) на портал обеспечения Apple под новым идентификатором Apple ID
  4. Утвердить запрос и загрузите файл .cer
  5. security unlock-keychain
  6. security add-certificate ios_development.cer

Это приближает нас на один шаг ...

Проблема 3: Профиль инициализации и разблокировка связки ключей

Я создал специальный профиль обеспечения на портале Provisioning Portal только для использования с CI в надежде, что в случае чего-то плохого я немного уменьшил влияние. Лучшая практика или чрезмерная осторожность?

  1. sudo su jenkins
  2. mkdir ~ / Library / MobileDevice
  3. mkdir ~ / Library / MobileDevice / Provisioning \ Profiles
  4. Переместите профиль обеспечения, который вы настроили на портале Provisioning Portal, в этот новая папка. Теперь мы в двух шагах от возможности запускать xcodebuild из командной строки от имени jenkins, а это значит, что мы также близки к возможности получить работающие сборки Jenkins CI.
  5. security unlock-keychain -p
  6. xcodebuild -target MyTarget -sdk iphoneos

Теперь мы получаем успешную сборку из командной строки при входе в систему как демон jenkins, поэтому, если мы создадим бесплатную -style и добавив эти последние два шага (№5 и №6 выше), мы сможем автоматизировать сборку нашего проекта iOS!

Возможно, в этом нет необходимости, но я почувствовал себя лучше, вернув jenkins UserShell обратно в / usr / bin / false после того, как я успешно выполнил всю эту настройку. Я параноик?

Проблема 4: Связка ключей по умолчанию все еще недоступна!

( РЕДАКТИРОВАТЬ: я опубликовал правки в свой вопрос, перезагрузился, чтобы убедиться, что мое решение было на 100%, и, конечно же, я пропустил шаг )

Даже после всех шагов выше, вам необходимо изменить список Launch Daemon в /Library/LaunchDaemons/org.jenkins-ci.plist, как указано в этот ответ . Обратите внимание, что это также ошибка openrdar .

Это должно выглядеть так: 





        EnvironmentVariables
        
                JENKINS_HOME
                /Users/Shared/Jenkins/Home
        
        GroupName
        daemon
        KeepAlive
        
        Label
        org.jenkins-ci
        ProgramArguments
        
                /bin/bash
                /Library/Application Support/Jenkins/jenkins-runner.sh
        
        RunAtLoad
        
        UserName
        jenkins
        
        SessionCreate

При такой настройке я бы также порекомендовал плагин Xcode для Jenkins , который немного упрощает настройку скрипта xcodebuild. На этом этапе я также рекомендую прочитать справочные страницы по xcodebuild - черт возьми, вы так далеко зашли в Терминале, не так ли?

Эта установка не идеальна, и мы будем благодарны за любые советы или идеи.

Мне было нелегко выбрать «правильный» ответ, поскольку для решения своей проблемы я использовал сборник мнений почти всех. Я попытался дать всем хотя бы один голос, но дать ответ Саймону, потому что он в основном отвечал на исходный вопрос.Кроме того, Сами Тикка заслуживает большой похвалы за его усилия, направленные на то, чтобы Дженкинс работал через AppleScript как простое приложение для OS X. Если вы заинтересованы только в том, чтобы Дженкинс начал работать быстро в рамках вашего пользовательского сеанса (то есть не в качестве безголового сервера), его решение гораздо больше похоже на Mac.

Я надеюсь, что мои усилия вызовут дальнейшее обсуждение и помогут следующей бедной душе, которая приходит в голову, думая, что сможет получить настройку Jenkins CI для своих проектов iOS за выходные из-за всех замечательных вещей, которые они слышали об этом.

Обновление: 9 августа 2013 г.

С таким количеством голосов и избранных, я подумал, что вернусь к этому 18 месяцев спустя и извлечу некоторые краткие уроки.

Урок 1: Не раскрывайте Jenkins в общедоступном Интернете

На конференции WWDC 2012 года я задал этот вопрос инженерам Xcode и OS X Server. Я получил какофонию "не делай этого!" ни от кого я спросил. Все они согласились с тем, что автоматизированный процесс сборки - это здорово, но что сервер должен быть доступен только в локальной сети. Инженеры OS X Server предложили разрешить удаленный доступ через VPN.

Урок 2: Теперь есть новые варианты установки

Я недавно выступал с докладом на CocoaHeads о моем опыте работы с Jenkins, и, к своему большому удивлению, я обнаружил несколько новых методов установки - Homebrew и даже Bitnami Mac App Store версия. Это определенно стоит проверить. Джонатан Райт подробно описывает, как заставить Homebrew Jenkins работать .

Урок 3: Нет, серьезно, не открывайте свою сборку в Интернете

Из исходного сообщения довольно ясно, что я не системный администратор и не эксперт по безопасности. Здравый смысл в отношении личных вещей (брелки, учетные данные, сертификаты и т. Д.) Заставил меня чувствовать себя довольно неловко, когда я размещал свой ящик Jenkins в Интернете. Ник Арнотт из Neglected Potential смог довольно легко подтвердить мои хиби-джиби в этой статье .

TL; DR

Мои рекомендации другим, кто хочет автоматизировать процесс сборки, изменились за последние полтора года.Убедитесь, что ваша машина Jenkins находится за вашим брандмауэром. Установите и настройте Jenkins в качестве специального пользователя Jenkins с помощью установщика, версии Bitnami Mac App Store, AppleScript Сами Тикки и т. Д .; это решает большую часть головной боли, о которой я подробно говорил выше. Если вам нужен удаленный доступ, настройка служб VPN в OS X Server занимает максимум десять минут. Я использую эту установку более года и очень ей доволен. Удачи!

107
задан Community 23 May 2017 в 11:47
поделиться