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

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

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

xcodebuild -configuration AdHoc -sdk iphoneos2.2 clean build

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

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

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

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

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

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 

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

Решение состоит в следующем:

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

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

 security dump-keychain -i login.keychain 

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

 security import login.keychain -P "" -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 "" login.keychain

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

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

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

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

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

 security unlock-keychain login.keychain 

Вторая – (пустая) кодовая фраза,

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

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

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

    ssh someuser @ localhost ~ / build-script

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

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

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

 SessionCreate  

Таким образом, весь ci.plist будет выглядеть так:

     Label Jenkins UserName user GroupName staff ProgramArguments  /usr/bin/java -Xmx512m -jar /path/to/jenkins/jenkins.war  RunAtLoad  KeepAlive  EnvironmentVariables  JENKINS_HOME /path/to/jenkins/home  SessionCreate    

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

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

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

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

 $ security list-keychain "/Users/user_account_name/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 часов вниз для стока для меня. Вздох.

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

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

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

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

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

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

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

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

 $ 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 

Есть идеи?

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

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

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

  1. войдите в систему как системный администратор, как описано здесь
  2. создайте ios.keychain ключей для подписания (например, 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 

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

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

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

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

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

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

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

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

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

Я сделал:

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

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

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

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

  • security unlock-keychain на эту security unlock-keychain

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

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

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

Давайте будем гением компьютера.