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

Резюме:

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

Мотивация:

Запустите автономный сервер CI, который следует общепринятым рекомендациям по запуску служб в OS X ( Как автоматизировать ваше приложение для iPhone создается с помощью Hudson

  • 15 июня 2011 г. - Дженкинс в Mac OS X; git w /ssh открытый ключ
  • 23 июня 2011 г. - Непрерывное развертывание приложений для iOS с Jenkins и TestFlight
  • 26 июля 2011 г. - Отсутствие сертификатов и ключей в связке ключей при использовании Jenkins /Hudson в качестве непрерывной интеграции для разработки под iOS и Mac
  • 30 августа 2011 г. - Файл обеспечения Xcode не найден в Jenkins
  • 20 сентября 2011 г. - Как настроить Jenkins CI на Mac
  • 14 сентября 2011 г. - Как запустить Jenkins на Mac
  • 12 ноября 2011 г. - Howto: установить Jenkins на OS X и заставить его собирать вещи для Mac
  • 23 января 2012 г. - Предстоящие изменения установщика Jenkins OSX
  • 7 марта 2012 г. - Благодарим за использование установщика OSX
  • Процесс:

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

    Обсуждение

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

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

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

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

    sudo -u jenkins security default-keychain ... выдает "Брелок по умолчанию не найден"

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

      sudo su jenkins литий> cd ~/Library литий> mkdir Keychains литий> cd Keychains литий> security create-keychain <keychain-name>.keychain литий> security default-keychain -s <keychain-name>.keychain литий>

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

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

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

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

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

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

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

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

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

    Проблема 3. Подготовка профиля и разблокировка связки ключей

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

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

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

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

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

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

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

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

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

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

    Эта настройка не идеальна, и любые советы или советы очень важны.

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

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


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

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

    Урок 1. Не открывайте Дженкинса в общедоступном Интернете

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

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

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

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

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

    TL; DR

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

    104 голоса | спросил edelaney05 12 FebruaryEurope/MoscowbSun, 12 Feb 2012 03:57:28 +0400000000amSun, 12 Feb 2012 03:57:28 +040012 2012, 03:57:28

    0 ответов


    Похожие вопросы

    Популярные теги

    security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132