Отсутствие сертификатов и ключей в связке ключей при использовании Jenkins / Hudson в качестве непрерывной интеграции для разработки под iOS и Mac

Question

Я пытаюсь улучшить Hudson CI для iOS и запустить Hudson, как только система запустится.Для этого я использую следующий скрипт launchd:

<?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>Label</key>
    <string>Hudson CI</string>
    <key>ProgramArguments</key>
    <array>
    <string>/usr/bin/java</string>
    <string>-jar</string>
    <string>/Users/user/Hudson/hudson.war</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>UserName</key>
    <string>user</string>
</dict>
</plist>

Это работает нормально, но когда xcodebuild, запущенный Hudson, пытается подписать приложение, оно не работает, потому что не может найти правильный ключ / сертификатв брелок.Однако пара ключ / сертификат существует, так как она работает правильно, если я запускаю Hudson из командной строки.

У вас есть идеи, почему это происходит?

Answer 1

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

В дополнение к указанию элемента UserName в plist, как предполагает принятый ответ, хитрость для получения доступа к обычным цепочкам для ключей для пользователя, указанного вами в UserName, заключается также в добавлении элемента SessionCreate со значением true в файл plist - /Library/LaunchDaemons/org.jenkins-ci.plist:

<?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>wheel</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>
        <key>SessionCreate</key>
        <true />
</dict>

Затем перезапустите демон и попробуйте запустить задание в Jenkins, которое вызывает цепочки безопасности list-keychains - и вы больше не должны видеть System.keychain в качестве единственной записи, кроме обычного входа в систему и любых пользовательских цепочек ключей, которые вы, возможно, добавили в список брелков для пользователя "jenkins".

Сейчас я использую сертификаты для подписи кодов из пользовательской цепочки ключей на моем сервере сборки Jenkins - я не установил никаких сертификатов или ключей в моей цепочке ключей системы.

Answer 2

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

<key>UserName</key>
<string>user</string>

Отсутствующие сертификаты и ключи должны быть в системной цепочке ключей (/Library/Keychains/System.keychain).Я нашел это после того, как настроил задание jenkins, которое выполняет несколько вызовов оболочки security.Интересен тот, который security list-keychains:

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

. Это цепочки ключей, которые Дженкинс будет искать сертификаты и ключи, поэтому они должны быть там.После того, как я перенес свои сертификаты туда, это работает.Убедитесь, что вы также скопировали сертификат «Apple Worldwide Developer Relations Certification Authority» в системную цепочку ключей, в противном случае вы увидите ошибку CSSMERR_TP_NOT_TRUSTED из codesign.

Также можно зарегистрировать больше цепочек для ключей с помощью security list-keychains -s [path to additional keychains].Я не пробовал, но что-то вроде security list-keychains -s $HOME/Library/Keychains/login.keychain, так как может сработать выполнение оболочки до сборки в jenkins.

РЕДАКТИРОВАТЬ: Я пытался добавить цепочку ключей пользователя в поискпуть с -s, но я не смог заставить его работать.Поэтому сейчас нам нужно скопировать наши сертификаты и ключи в системную цепочку ключей.

РЕДАКТИРОВАТЬ ^ 2: Читать и использовать joensson ' solution вместо моего, онему удалось получить доступ к цепочке для ключей пользователей, а не только к системной цепочке для ключей.

Answer 3

У нас была та же проблема с запущенным Hudson-слэйвом, что и с запущенным демоном на Mac OSX Lion.Это сработало, когда мы запустили раб с веб-старта.Единственное различие, которое мы обнаружили, было в другой переменной окружения.

com.apple.java.jvmTask=WebStart

работает, если мы запустили ведомое устройство без веб-запуска, переменная была

com.apple.java.jvmTask=CommandLine.java

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

<?xml version"1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>jenkins</string>
    <key>UserName</key>
    <string>apple</string>
    <key>Program</key>
    <string>/usr/bin/javaws</string>
    <key>ProgramArguments</key>
    <array>
        <string>-verbose</string>
        <string>-wait</string>
        <string>http://<hudson-hostname>:8080/computer/<node-name>/slave-agent.jnlp</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
    <key>WorkingDirectory</key>
    <string>/Users/apple</string>
</dict>
</plist>

Answer 4

Я столкнулся с той же проблемой и попытался изменить имя пользователя в /Library/LaunchDaemons/org.jenkins-ci.plist, как описано в одном из других постов.Однако, это все еще не работало, и некоторое неясное NullPointerException не помогло мне идентифицировать проблему.Поэтому я бы просто поделился своим решением: мне также пришлось сменить владельца каталога JENKINS_HOME (также определенного в org.jenkins-ci.plist):

chown -R myBuildUser /Users/Shared/Jenkins

myBuildUser - это пользователь, у которого естьсертификаты установлены, и это пользователь, которого я указал в файле plist.

Это решение было совершенно очевидно, когда я наконец осознал его - но мне потребовалось несколько часов, чтобы узнать об этом, так что, надеюсь, этот пост может сэкономить время для кого-то еще: -)

Answer 5

Вы можете попробовать мой Jenkins.app, https://github.com/stisti/jenkins-app, альтернативный способ запуска Jenkins. Он запускает Jenkins в сеансе пользователя, поэтому доступ к связке ключей не является проблемой.

Answer 6

Чтобы сохранить разделенную цепочку для ключей для Дженкинса / Хадсона, я переместил элемент launchctl из

/Library/LaunchDaemons/org.jenkins-ci.plist

в

/Users/Shared/Jenkins/Home/Library/LaunchAgents/org.jenkins-ci.plist

И это позволяет мне получить доступ к закрытой цепочке для ключей, созданной для Jenkins.

Answer 7

Мы столкнулись с точно такой же проблемой как на Lion, так и на SnowLeopard. Нам пришлось запустить Tomcat / Hudson с заданиями xcodebuild в качестве службы. При запуске из командной строки xcodebuild может получить доступ к login.keychain, чтобы использовать содержащийся сертификат. Но после перезагрузки ящика login.keychain не был виден xcodebuild, и поэтому подпись не удалась.

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

<plist version="1.0">
 <dict>
   <key>Label</key>
   <string>${LAUNCH_LABEL}</string>
   <key>Disabled</key>
   <false/>
   <key>RunAtLoad</key>
   <true/>
   <key>ProgramArguments</key>
   <array>
     <string>${INSTALL_DIR}/start.sh</string>
   </array>
   <key>StandardOutPath</key>
   <string>${INSTALL_DIR}/tomcat-stdout.log</string>
   <key>StandardErrorPath</key>
   <string>${INSTALL_DIR}/tomcat-stderr.log</string>
 </dict>
</plist>

Демон запуска, называемый простым скриптом ( start.sh ), имитирующий полный вход в систему и запускающий требуемую программу

su -l username -c program

Теперь, даже после загрузки, xcodebuild может получить доступ к login.keychain. Это также работает на Snow Leopard, но, если вы закроете пользовательский login.keychain в параллельном сеансе (например, vnc login / logout), цепочка для ключей будет потеряна. Лев ведет себя иначе. Кажется, что Lion отделяет цепочку для ключей от пользователя и назначает ее для сеанса входа в систему.

Answer 8

Для ручной подписи Переместите свой сертификат из логина в систему в связке ключей. Логин не доступен во время архивирования и создания iPA.

Answer 9

Добавление этого, поскольку у меня была та же проблема, но ни одно из этих решений не помогло мне.

Моя проблема была вызвана тем, что после обновления сертификата подписи нужно было истечь. После обновления xcode и запуск xcodebuild вручную работали нормально, НО Дженкинс не смог подписать приложение.

Вот как я это исправил:

1. Просмотрите брелок и найдите ключ . По какой-то причине, которую я не понимаю, это дало нам разные результаты.

2. Убедитесь, что закрытый ключ находится на уровне системы (если его нет, перетащите его на значок системы слева.

Answer 10

Добавление SessionCreate и настройка большого количества сертификатов на «всегда доверять» в диспетчере цепочки для ключей работали для меня с buildbot, запущенным из plist ... но в какой-то момент кодовая подпись начала давать сбой с CSSMERR_TP_NOT_TRUSTED.Я восстановился, установив для сертификата iPhone Distribution «использование системных значений по умолчанию» в диспетчере цепочки для ключей.Даже после перезагрузки без входа в систему ведомый buildbot смог подписать код, вот так.