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

Question

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

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

xcodebuild -configuration AdHoc -sdk iphoneos2.2 clean build

Проблема, с которой я столкнулся, заключается в том, что следующая строка не работает с разветвленного терминала (с использованием 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

обновление для людей, сталкивающихся с похожими проблемами с 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 скрипт у меня такой же ** Взаимодействие с пользователем не допускается ** ошибка. При запуске из оболочки 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 ""

UPDATE: У меня возникла небольшая проблема позже, когда скрипт запускается из веб-скрипта или 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 и видите, что ваша пользовательская цепочка для ключей появляется в списке КУДА-ТО, но она все еще не работает, возможно, вы столкнулись с проблемой, с которой я столкнулся, когда цепочки для ключей проверяются по порядку список поиска, и так как я не разблокировал 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 9

Разблокировка брелка логина у меня не сработала. Создание отдельной цепочки для ключей с помощью 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 # XcodePlugin-User взаимодействия не допускается

Answer 10

Я использую 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