Запуск xcodebuild с разветвленного терминала

Question

Я пытаюсь настроить сервер автоматической сборки для приложения iPhone. Я хотел бы иметь возможность проводить ночные бета-тесты adhoc, чтобы тестировщики могли следить за разработкой.

Я успешно установил xcode xcode для выполнения сборок adhoc, и я также могу запустить сборку из командной строки:

xcodebuild -configuration AdHoc -sdk iphoneos2.2 чистая сборка

У меня проблема в том, что следующая строка не работает с разветвленного терминала (с помощью nohup или screen) и потерпела неудачу со следующим

Ошибка CodeSign. Идентификация подписи кода "Распределение iPhone: XXXXX" не соответствует ни одному сертификату подписи кода в вашей цепочке для ключей. После добавления в цепочку для ключей коснитесь файла или очистите проект, чтобы продолжить.

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

Спасибо за вашу помощь

Answer 1

У меня была ошибка. Взаимодействие с пользователем не разрешено, и она была решена путем разблокировки брелка.

security unlock-keychain /Users/yannooo/Library/Keychains/login.keychain

Я также попытался поместить свои сертификаты в цепочку для ключей Системы, и это работало. Мое окончательное решение состояло в том, чтобы поместить все связанные с iPhone сертификаты в выделенную цепочку для ключей с именем iPhone.keychain с помощью приложения Keychain Access.

security list-keychains -s /Users/yannooo/Library/Keychains/iPhone.keychain 
security unlock-keychain -p keychainpassword /Users/yannooo/Library/Keychains/iPhone.keychain 

Answer 2

Здесь есть два (возможно, три!) Компонента. Одним из них является брелок должен быть разблокирован. Во-вторых, в цепочке для ключей есть список контроля доступа, который сообщает, какие разрешения предоставляются приложениям в разблокированном состоянии. Таким образом, даже если у вас успешно разблокирована цепочка для ключей, если возможность доступа к закрытому ключу и подписи с ним не предоставляется /usr/bin/codesign тогда вы все равно получите это сообщение. Наконец, если вы работаете в Mac OS Sierra, идентификатор раздела по умолчанию, назначенный для ключей, неверен, чтобы быть совместимым с codesign двоичный файл.

Решение заключается в следующем:

1) Если у вас есть доступ к графическому интерфейсу Keychain Access, то вы можете вручную предоставить доступ к каждой программе или /usr/bin/codesign, щелкнув правой кнопкой мыши свой закрытый ключ, выбрав вкладку "Контроль доступа", а затем выбрав "Разрешить все приложения". для доступа к этому пункту "радио" или в списке "Всегда разрешать доступ этим приложениям".

2) Если вы столкнулись с этой ошибкой, скорее всего, вы пытаетесь запустить codesign для не авторизованного пользователя. В этом случае у вас явно нет доступа к графическому интерфейсу "Keychain Access". В этих случаях вы проверяете sign для приложения отсутствует авторизация <null>что, по-видимому, означает все приложения, или конкретно /usr/bin/codesign используя:

security dump-keychain -i login.keychain

Однако вы не можете добавлять или изменять атрибуты контроля доступа в интерактивном режиме по какой-то причине - только удалять! Вы фактически должны вручную удалить ключ и повторно добавить его в цепочку для ключей, указав -T флаг.

security import login.keychain -P "<password>" -T /usr/bin/codesign

куда -T определяет

-T  Specify an application which may access the imported key (multiple -T options are allowed)

3) Если вы работаете в Mac OS Sierra, измените идентификатор раздела, включив в него apple раздел. Предположительно, это пространство имен, назначенное codesign потому что он был распространен Apple.

security set-key-partition-list -S apple-tool:,apple: -k "<password>" login.keychain

ПРИМЕЧАНИЕ: apple-tool раздел вставляется security инструмент, поэтому команда выше сохраняет этот раздел. Для получения дополнительной информации по этому аспекту см.: http://www.openradar.me/28524119

Answer 3

Другое решение:

• Откройте брелок доступа
• Щелкните правой кнопкой мыши на закрытом ключе
• Выберите "Получить информацию"
• Выберите вкладку "Контроль доступа"
• Нажмите "Разрешить всем приложениям доступ к этому элементу"
• Нажмите "Сохранить изменения"
• Введите ваш пароль
• наслаждаться

Answer 4

Не могли бы вы использовать security list-keychains -s ${HOME}/Library/Keychains/login.keychain внутри процесса сборки, чтобы явно добавить вашу цепочку ключей входа в систему в список поиска? Похоже, что из разветвленного терминала процесс сборки не видит вашу цепочку ключей пользователя. Это может иметь смысл, если список поиска цепочки для ключей основан на вашем текущем сеансе безопасности - разветвленный сеанс терминала покинет сеанс входа в систему так же, как если бы вы ssh через петлевое соединение.

Answer 5

обновление для людей, сталкивающихся с подобными проблемами с Дженкинсом:

Если вы настроили свой Mac для запуска jenkins через LaunchDaemons, вам нужно обязательно добавить

<key>SessionCreate</key>
<true />

Таким образом, весь 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>Label</key>
 <string>Jenkins</string>
 <key>UserName</key>
 <string>user</string>
 <key>GroupName</key>
 <string>staff</string>
 <key>ProgramArguments</key>
 <array>
 <string>/usr/bin/java</string>
 <string>-Xmx512m</string>
 <string>-jar</string>
 <string>/path/to/jenkins/jenkins.war</string>
 </array>
 <key>RunAtLoad</key>
 <true/>
 <key>KeepAlive</key>
 <true/>
 <key>EnvironmentVariables</key>
   <dict>
     <key>JENKINS_HOME</key>
     <string>/path/to/jenkins/home</string>
   </dict>
 <key>SessionCreate</key>
 <true />
</dict>
</plist>

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

Разница, которую большинство людей также видели, состоит в том, что если вы запуститецепочку ключей безопасности, вы получите:

$ security list-keychain
  "/Library/Keychains/System.keychain"
  "/Library/Keychains/System.keychain"

Но при запуске в оболочке ssh я получаю:

$ security list-keychain
    "/Users/<i>user_account_name</i>/Library/Keychains/login.keychain"
    "/Library/Keychains/System.keychain"

И большинство людей будут иметь все свои ключи / сертификаты и т. Д. В цепочке для ключей учетной записи пользователя. Как и предполагали некоторые люди, легко создать новую цепочку ключей, отличную от цепочки ключей пользователя, и загрузить ее для подписи XCode. Я закончил тем, что выложил свой здесь: /Library/Keychains/sysiphone.keychain

Я думаю, что проблема заключается в том, что для моей установки (и, возможно, для вашей тоже) вы работаете в другом домене настроек безопасности (система против пользователя). Наконец, вот как у меня появился sysiphone.keychain:

$ sudo security list-keychains -d system -s "/Library/Keychains/sysiphone.keychain"
Password: *****
$ security list-keychains -d system
    "/Library/Keychains/sysiphone.keychain"

... и волшебным образом в Дженкинсе начали накапливаться вещи. Ух ты... это было около 4 часов без дела для меня. Вздох.

Answer 6

Хорошо, проблема была в двух вещах для меня, во-первых, была разблокировка брелка;

security unlock-keychain login.keychain

Второй был (пустой) пароль,

security import blahblahbackup.p12 -k login.keychain -T /usr/bin/codesign -P ""

ОБНОВЛЕНИЕ: У A была небольшая проблема позже, когда скрипт запускается из веб-скрипта или STH. как это. Он просто видит /Library/Keychains/System.chain. Поэтому я нашел грязный обходной путь (который может привести к проблемам с безопасностью, но для меня это нормально);

• В моем случае настройте логин пользователя pubkey ssh (от пользователя, который хочет вызвать скрипт сборки, до реального пользователя, у которого есть сертификаты и который будет запускать xcodebuild). Apache работает как someuser и все для сборки настроено на someuser,

• и мой php-скрипт (для запуска сборки) вызывал ~/build-script. Я изменил это так:

  ssh someuser @ localhost ~ / build-script

так что работает в реальном tty, и все брелки доступны, все работает отлично.

Answer 7

Как говорит другой плакат,

security list-keychains -s  "~/Library/Keychains/login.keychain"

Но я думаю, что у вас есть доступ к login.keychain только после того, как вы вошли в систему, в контексте графического интерфейса пользователя (я только что проверил систему через SSH и экран, но я также вошел в систему через VNC).

Очевидно, что можно использовать launchctl, чтобы выбрать контекст графического интерфейса и запустить программу, но я подозреваю, что это работает только для "вошедшего в систему пользователя".

Если вы попытаетесь 'security show-keychain-info keychain-file'тогда вы получите следующую ошибку:

Взаимодействие с пользователем не допускается

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

Answer 8

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

$ security list-keychains
  "/Users/yannooo/Library/Keychains/login.keychain"
  "/Library/Keychains/System.keychain"

тогда как при использовании экрана у меня есть следующий вывод:

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

Так как мои сертификаты сборки хранятся в цепочке для ключей входа в систему, ошибка кода кода у меня выглядит нормально.

Кто-нибудь знает, как я мог бы назначить связку ключей для терминала? Я попробовал это без успеха

security login-keychain -s /Users/yannooo/Library/Keychains/login.keychain

Есть идеи?

Answer 9

Я использую Atlassian Bamboo 2.7 и OS X 10.7.3 Lion, и я попробовал все подходы, найденные в потоке, но я все еще получал ошибку "взаимодействие с пользователем не разрешено".

Проблема заключалась в том, что в сеансе удаленного терминала (в качестве "суперпользователя", такого как в случае Bamboo или другой автоматизированной системы сборки) цепочка для ключей, которая должна быть разблокирована с сертификатами подписи, отличается от того, что вы обычно видите (например, как показал Янн здесь), когда вы не являетесь суперпользователем.

То, что в конечном счете работало для меня, было сделать следующее:

1. Войдите в систему как системный администратор, как описано здесь
2. создать цепочку для ключей только для подписи (например, ios.keychain)
3. добавить сертификаты подписи к нему (вместе с сертификатом WWDRCA)

Проверьте это, перейдя su и работает security list-keychains на терминале. Вы должны увидеть ios.keychain среди списка. (sudo security list-keychains не покажу тоже самое)

sh-3.2# security list-keychains
"/private/var/root/Library/Keychains/login.keychain"
"/Library/Keychains/ios.keychain"
"/Library/Keychains/System.keychain"

Я обнаружил, что вам еще нужно добавить ios.keychain в область поиска, прежде чем делать unlock-keychain команда. В вашем скрипте сборки запустите следующие строки:

KEYCHAIN=/Library/Keychains/ios.keychain
# the -s option adds $KEYCHAIN to the search scope, while the -d option adds $KEYCHAIN to the system domain; both are needed
security -v list-keychains -d system -s $KEYCHAIN 
security -v unlock-keychain -p bambooiphone $KEYCHAIN

Answer 10

Если вы бежите security list-keychains и увидев, что ваша пользовательская цепочка для ключей появилась в списке КУДА-ТО в списке, но она все еще не работает, возможно, вы столкнулись с проблемой, с которой я столкнулся, когда цепочки для ключей проверяются по порядку из списка поиска, и так как я не был разблокирован login.keychain в моем сеансе SSH он потерпит неудачу, а не перейдет к следующей цепочке ключей в списке, которую я хотел разблокировать.

Настройка списка поиска для пользовательской цепочки для ключей, которую вы разблокируете security unlock-keychain работает. Использование этого метода из ответа Янна также удалит ваш login.keychain из списка поиска.

Чтобы сохранить login.keychain:

security list-keychains -s ~/Library/Keychains/custom.keychain ~/Library/Keychains/login.keychain

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

Answer 11

Разблокировка брелка логина у меня не сработала. Создание отдельной цепочки для ключей с помощью Keychain Access (называемой iOS) и последующее добавление этих команд в сборку сработало (при запуске Jenkins от моего собственного пользователя):

security -v list-цепочки для ключей -d system -s ~/Library/Keychains/iOS.keychain; security -v разблокировать-связка ключей -p пароль ~ / Библиотека / Связки ключей / iOS.keychain;

Это выглядит более многообещающе: https://wiki.jenkins-ci.org/display/JENKINS/Xcode+Plugin

Answer 12

Если вы выполняете xcodebuild от имени пользователя root (которым вы пользуетесь при sudo), вам необходимо войти в систему как root и поместить сертификаты подписи в цепочку ключей root. Затем разблокируйте брелок с безопасностью, как указано выше.

Answer 13

Я сделал:

• удалять login.keychain из списка

• создать собственный брелок в $HOME/Library/Keychains/

• добавить его в список цепочки для ключей (я не указал какой-либо конкретный домен)

• установить его по умолчанию

• вызов security unlock-keychain в теме

• добавить глобальный сертификат подписи (WWDRCA) к нему

• импортировать закрытый ключ и сертификаты разработки и распространения к нему

Если есть login.keychainЯ все еще получаю сообщение об ошибке "Взаимодействие с пользователем не разрешено". Таким образом удаляя login.keychain с помощью security delete-keychain наконец-то помог!