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

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

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

xcodebuild -configuration AdHoc -sdk iphoneos2.2 clean build

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

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

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

Спасибо за помощь

Ответ 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 

Ответ 2

Это два (возможно, три!) компонента. Один - брелок должен быть разблокирован. Во-вторых, в цепочке ключей есть список управления доступом, который сообщает, какие разрешения предоставляются приложениям в незаблокированном состоянии. Таким образом, даже если у вас есть keychain успешно разблокирована, если возможность доступа к закрытому ключу и подписаться с ним не предоставляется /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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

security unlock-keychain login.keychain

Вторая была (пустая) парольная фраза,

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

UPDATE: У A была небольшая проблема позже, когда script запускается из сети script или sth. как это. Он просто видит /Library/Keychains/System.chain. Поэтому я нашел грязное обходное решение (что может привести к проблемам безопасности, но нормально для меня);

  • setup pubkey ssh login (от пользователя, который хочет вызвать build script, фактическому пользователю, который имеет сертификаты и будет запускать xcodebuild) в моем случае, это тот же пользователь. Apache работает как someuser, и все для сборки настроено на someuser.
  • и мой php script (для запуска сборки) вызывал ~/build- script. Я изменил это следующим образом:

    ssh someuser @localhost ~/build- script

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

Ответ 6

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

Если вы настроили свой 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 script Я получил то же самое ** Взаимодействие с пользователем не допускается ** ошибка. При работе с оболочкой ssh ​​мой script работал нормально.

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

$ 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 часов вниз для стока для меня. Вздох.

Ответ 7

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

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

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

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

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

Взаимодействие с пользователем не разрешено

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

Ответ 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

Любые идеи?

Ответ 9

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

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

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

  • войдите в систему как системный администратор, как описано здесь
  • создать цепочку ключей для подписания (например, ios.keychain)
  • добавить к нему сертификаты подписи (вместе с сертификатом 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. В вашей сборке script выполните следующие строки:

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

Ответ 10

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

security -v list-keychains -d system -s ~/Library/Keychains/iOS.keychain; безопасность -v разблокировка-keychain -p пароль ~/Library/Брелки/iOS.keychain;

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

Ответ 11

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

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

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

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

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

Ответ 12

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

Ответ 13

Я сделал:

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

  • создать собственную цепочку ключей в $HOME/Library/Keychains/

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

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

  • вызов security unlock-keychain на нем

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

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

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