«Взаимодействие с пользователем не допускается» при попытке подписать приложение OSX с использованием кодового знака


145

Наша автоматизированная сборка работает на Jenkins. Сама сборка выполняется на подчиненных, причем подчиненные выполняются через SSH.

Я получаю ошибку:

00:03:25.113 [codesign-app] build/App.app: User interaction is not allowed.

Я попробовал каждое предложение, которое я видел до сих пор в других сообщениях здесь:

  • Использование безопасности unlock-keychain непосредственно перед подписью для разблокировки цепочки для ключей.
  • Перемещение подписывающего ключа в собственную цепочку для ключей.
  • Перемещение подписывающего ключа в связку ключей входа.
  • Перемещение подписывающего ключа в системную связку ключей.
  • Ручная настройка списков цепочек для ключей только для цепочки для ключей, которая содержит ключ.

Во всех случаях я получаю одну и ту же ошибку.

В попытке диагностировать проблему, я попытался выполнить команду «security unlock-keychain» на своем локальном терминале и обнаружил, что она фактически не разблокирует цепочку для ключей - если я смотрю в Keychain Access, символ блокировки все еще там. Это тот случай, когда я передаю пароль в командной строке или разрешаю ему запрашивать его. Разблокировка той же цепочки для ключей с помощью графического интерфейса предложит мне ввести пароль, а затем разблокировать его. Кроме того, если я бегу «безопасности с замком-брелок», я сделать увидеть блокировку сразу после запуска команды. Это заставляет меня думать, что unlock-keychain на самом деле не работает. Я испытываю такое же поведение на Lion (который мы используем для сборщиков) и Mavericks (на котором я разрабатываю).

Затем я попытался добавить -v ко всем командам безопасности:

list-keychains "-d" "system" "-s" "/Users/tester/.secret/App.keychain"
Listing keychains to see if it was added: ((
        "/Library/Keychains/System.keychain"
))
unlock-keychain "-p" "**PASSWORD**" "/Users/tester/.secret/App.keychain"
build/App.app: User interaction is not allowed.

Из этого может показаться, что списки-брелки - это то, что не работает. Может быть, ни работа. : /

Здесь есть похожий вопрос . Решение интересное - установите «SessionCreate» в true в launchctl. Но я не опираюсь на мастер - мой процесс сборки запускается из SSH на подчиненной сборочной машине. Может быть, есть способ командной строки сделать то, что делает launchctl, когда вы запускаете "SessionCreate"?


Как установить пароль брелка на кружке?
Сачин Кумарам

@SachinKumaram звучит как новый жизнеспособный вопрос?
Trejkaz

Ответы:


205

Я тоже боролся с этим. Ничего не помогало, пока я не попробовал предложение на http://devnet.jetbrains.com/thread/311971 . Спасибо Ашиш Агравал!

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

вкладка контроля доступа


2
Пожалуйста. Вы также можете рассмотреть возможность добавления кодового знака в список приложений внизу, а не разрешать все приложения, как я. Это уже есть на моем скриншоте, но я думаю, что изначально этого не было.
bmauter

3
Мне пришлось развернуть каталог / usr с apple.stackexchange.com/a/34872/6052 , чтобы добавить его codesignв список «Всегда разрешать».
Хит Границы

24
просто обратите внимание, что в дополнение к этому вы должны сделать все security unlock-keychainэто тоже
cwd

13
Кроме того, вы можете захотеть перенести свои ключи из логина в систему, чтобы они были доступны при удаленной сборке на вашем компьютере.
Кристиан

8
Кто-нибудь знает способ сделать это из командной строки? Моя удаленная сборочная машина не позволяет мне делать это через общий доступ к экрану из соображений безопасности .
devios1

78

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

По сути, похоже, что это сводится к тому, что на -d systemсамом деле не работает. Поэтому многие ответы на другие вопросы здесь, вероятно, следует обновить, чтобы отразить это.

security -v list-keychains -s "$KEYCHAIN" "$HOME/Library/Keychains/login.keychain"
security list-keychains # so we can verify that it was added if it fails again
security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN"
codesign --sign "$SIGNER_IDENTITY" --force --signature-size 9600 \
         --resource-rules src/AppResourceRules.plist --timestamp --verbose \
         "$APP"

17
Спасибо. Я смог сузить это. Просто выполните следующую команду прямо перед попыткой сборки: security -v unlock-keychain -p "$ KEYCHAIN_PASSWORD" "$ HOME / Library / Keychains / login.keychain"
pir800

3
Таким образом, нет никакого способа получить доступ codesignчерез ssh без фактического сохранения пароля для входа в некоторый скрипт?
чакрит

2
@chakrit в приведенном выше примере, я передаю только пароль брелка, а не пароль для входа. Я понимаю, что для многих пользователей цепочка ключей входа является единственной цепочкой ключей, но в нашем случае мы храним ключи подписи в отдельном хранилище ключей, чтобы их было проще синхронизировать для сборки машин. Но да, многие из этих вещей кажутся довольно неудобными для автоматических сборок, что заставляет меня задуматься, даже если Apple даже делает автоматические сборки.
Trejkaz

@Trejkaz о хорошо, по крайней мере обмен паролем связки ключей не так плох.
Чакрит

В моем случае использования автоматических удаленных сборок сохранение пароля цепочки для ключей в .envфайле не так уж и плохо, поскольку .envфайл уже содержит секретные ключи, например. AWS и Heroku. В нашем случае учетные данные кода, связанные со сборкой, хранятся во вновь созданной цепочке для ключей, которая затем удаляется после сборки. Затем он воссоздается снова для следующей сборки. Тем не менее, loginцепочка для ключей все еще должна быть открыта, поэтому security unlock-keychain -p pass login.keychainздесь отсутствовала ссылка. Спасибо!
Петрус Репо

19

Ни один из других ответов не работал для меня.

Что в конечном итоге спасло меня, был этот пост

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

Исправить:

security set-keychain-settings -t 3600 -l ~/Library/Keychains/login.keychain

2
На El Capitan вы можете сделать это и через пользовательский интерфейс. Просто откройте приложение цепочки для ключей, щелкните правой кнопкой мыши на вашей цепочке для ключей (логин, система и т. Д.) И выберите что-нибудь, что лучше всего соответствует «изменить настройки для <your_keychain>».
rubybeginner

Это всегда возвращает доступ к моей системной связке ключей Confirmдаже после изменения доступа. : /
Алекс Заватоне

Это было полезно для меня!
Нори

Я боролся с этим в течение 2 дней, прежде чем я нашел ваш комментарий, спасибо !!!
Гилад Новик

16

Попробуйте позвонить security unlock-keychainи codesignв виде однострочной команды. Это помогло мне. Что-то вроде:

security unlock-keychain -p <password> /Users/<user>/Library/Keychains/login.keychain && codesign --force --verify --verbose --sign "<certificate id>" <app name>

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

1
Для меня они не одинаковы. Я звоню им через муравья, sshexecи каждый раз он создает новую сессию ssh.
Жека Козлов

2
Вы также можете сделать более одной строки в течение одного сеанса SSH, если вы действительно этого хотите. Так что ... это все то же самое, кроме обработки ошибок.
Trejkaz

13

Использование безопасности для создания цепочки для ключей для / usr / bin / codesign

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

В эти дни, чтобы codesignне дать errSecInternalComponentвам, вы должны получить правильный список разделов (ACL). Я пойду через шаги:

Создать брелок

security create-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"

на этом этапе цепочка для ключей разблокирована, но не появится в Keychain Access.

Добавить новый брелок в список поиска

security list-keychains -s "${KEYCHAIN_NAME}" "${OLD_KEYCHAIN_NAMES[@]}"

Добавьте новый брелок в список. Если вы сначала не list-keychainsполучите исходный список, его больше не будет login.keychainв вашем списке поиска.

Разблокировать брелок

security unlock-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"

Это избыточно, если вы создали цепочку для ключей выше, но если цепочка для ключей уже существует, это необходимо.

Удалить значения по умолчанию из брелка

security set-keychain-settings "${TESTING_KEYCHAIN}"

Без указания каких-либо аргументов это установит неограниченное время автоблокировки и удалит автоматическую блокировку в спящем режиме.

Импортируйте сертификаты подписи из .p12

security import "${DIST_CER}" -P "${CERTIFICATE_PASSWORD}" -k "${KEYCHAIN_NAME}" -T /usr/bin/codesign

Импортируйте сертификаты и дайте codesignдоступ через -Tопцию.

Установите ACL на связку ключей

security set-key-partition-list -S apple-tool:,apple: -s -k "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"

Это требование, которое многие люди пропускают. Вы можете увидеть, что делает macOS, используя dump-keychain. Который в случае кодирования требует apple:и apple-tool:. -sотносится к подписанию сертификатов.

Gitlab-Runner, Дженкинс и тому подобное

Для любого бегуна типа CI или системы сборки очень важно убедиться, что процесс запущен launchdправильно. Убедитесь, что ваш список содержит <SessionCreate> </true>.

Неправильное сопоставление владельца цепочки для ключей с процессом сборки и обеспечение того, что сеанс безопасности будет создан, приведет к разным головным болям. С диагностической точки зрения вы можете представить list-keychainsи посмотреть, соответствует ли результат вашим ожиданиям.

Это с launchd.plistman-страницы:

SessionCreate <boolean>

Этот ключ указывает, что задание должно порождаться в новом сеансе аудита безопасности, а не в сеансе по умолчанию для контекста. См Auditon (2) для деталей.

UserName <string>

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

GroupName <string>

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

Наконец код

Вы можете посмотреть хэш сертификатов подписи используя find-identity

security find-identity -p codesigning -v

Codesign рамки, dylib и др.

/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" "$SIGNABLE"

Создайте комплект приложений

/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" --entitlements entitlements.xcent "$SIGNABLE"

Заключительные замечания - если вы посмотрите на то, как Xcode делает это, они установят CODESIGN_ALLOCATEиспользовать тот, который содержится в Xcode, а не в /usr/bin.

export CODESIGN_ALLOCATE="$( xcrun --find codesign_allocate )"

Путь поиска установлен на ${PLATFORM_PATH}:${TOOLCHAIN_PATH}:${PATH}, где путь PLATFORM - это каталог / usr / bin для заданного целевого SDK, а TOOLCHAIN_PATH - это / usr / bin для инструментов узла Xcode.


3
Чувак, ты можешь окончательно написать статью об этом, я искал это 2 дня. Я не знаю, сколько сообщений и сообщений о стековом потоке я прочитал. Большое спасибо Вам !
Дэмиен

Спасибо за это полезное прохождение!
Тарас Никулин

ACL на связке ключей был недостающей частью для меня. спасибо за четкое объяснение, сэр!
Кейха

11

Поместите свои ключи в Системную цепочку для ключей


Но он все еще спрашивает имя пользователя и пароль
Durai Amuthan.H

Как поместить ключи в системный брелок ....... будет копировать вставить из брелка доступа работать?
Ашиш Карпе

Перетащите @AshishKarpe
Алистра

При перетаскивании по-прежнему возникает та же ошибка: === СОЗДАТЬ ЦЕЛЬ PatientPortal ПРОЕКТА PatientPortal С КОНФИГУРАЦИЕЙ Отладка === Проверить зависимости Не найдено профилей для 'com.abc.xyz360': Xcode не может найти профиль обеспечения, соответствующий 'com .abc.xyz360. Подписание кода требуется для продукта типа «Приложение» в SDK «iOS 10.2»
Ашиш Карпе

Он говорит , что вы не имеете профиль обеспечения , установленного на компьютере, не то, что вы пропустили ключи @AshishKarpe
Алистра

5

Так что это команда, которая работает. -Aчтобы запретить Mac запрашивать пароль. Импорт в system.keychain не требует графического интерфейса.

sudo security import <cert.p12> -k "/Library/Keychains/System.keychain" -P <passphrase> -A


3

Мой брелок был заблокирован. Он сопротивлялся моим достижениям, чтобы изменить этот факт ...

Keychain Access-> Keychain First Aid-> Repair, и вуаля !


2

Разблокировка брелка не достаточно. Вы также должны установить доступ к закрытому ключу «Разрешить всем приложениям доступ к этому элементу». И чтобы сделать это из командной строки, необходимо повторно импортировать ключ. Итак, чтобы принять вещи за раз:

Разблокируйте брелок для входа, если он заблокирован. Это не должно быть заблокировано, но в любом случае вот как вы это делаете:

security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "~/Library/Keychains/login.keychain"

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

security create-keychain -p 'temporaryPassword' MyKeychain.keychain
security list-keychains -d user -s login.keychain MyKeychain.keychain

Затем импортируйте свои сертификаты и соответствующие закрытые ключи в цепочку ключей входа в систему, используя параметр -A. Обратите внимание, что вам не нужно sudo для всего этого ...

security import <cert.p12> -k "~/Library/Keychains/login.keychain" -P <passphrase> -A

Параметр -A задает для вашего личного ключа значение «Разрешить всем приложениям доступ к этому элементу».

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


2

Помимо разблокировки цепочки для ключей (как упомянуто в других ответах), вам необходимо разрешить доступ всех приложений к токену аутентификации XCode в цепочке для ключей:

  • Выберите брелок для входа
  • Выберите категорию «Все товары»
  • Поиск по ключевому слову "xcode"
  • Выберите «Разрешить всем приложениям доступ к этому элементу» для всех токенов Xcode
  • Не забудьте добавить шаг разблокировки брелка (из предыдущих ответов)

Скриншот


1

Импортируйте ваши ключи в Системную связку ключей. Вы можете использовать эту команду:

sudo security import YourKey.p12 -k /Library/Keychains/System.keychain -P PasswordToYourKey -T /usr/bin/codesign

1

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


У меня была точно такая же проблема. Спасибо за ваш ответ. :)
Павел К

0

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

Даже после того, как вы получите ту же ошибку, попробуйте установить 'Unlock Keychain?' свойства в Jenkins и укажите путь к своему login.keychain в /Users/$ndomUSER‹/Library/Keychains/login.keychain

Я надеюсь, что Бог будет с тобой после этого.


0

В моем случае это было вызвано созданием цепочки для ключей с тайм-аутом по умолчанию, равным 300 с, и длинной компиляцией xcode, продолжительностью более 300 с. Обходной путь, для меня, должен был вызвать:

security set-keychain-settings -t <longer timeout in seconds> <keychain>

сразу после создания временной цепочки для ключей.


0

Я проверил все эти предложения и все еще имел проблемы с использованием Fastlane's gymв работе Дженкинса. У меня был установлен сертификат и разблокирована цепочка для ключей, и я смог кодировать на ведомом устройстве, когда я вручную запускал команду codeign на командной строке.

В качестве обходного пути, если Jenkins подключается к ведомому устройству, используя JNLP вместо SSH, вы сможете кодировать.


0

Для меня это происходит, когда вручную добавляется вторая цепочка для ключей, и она заблокирована. По какой-то причине codesignпытается получить доступ к заблокированной цепочке для ключей и терпит неудачу, даже если сертификаты находятся в цепочке для ключей входа (и разблокирована). Разблокировка второго решает проблему. Просто не имеет смысла для меня.


-1

Попробовав ряд вышеперечисленных решений. Я понял, что одним из факторов, которые я имел, было то, что я начинал сборку с помощью ION Console. Когда я вернулся к созданию сборки из приложения Terminal, все работало просто отлично.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.