"Взаимодействие с пользователем не разрешено", пытаясь подписать приложение OSX с использованием кода
Наша автоматическая сборка работает на Jenkins. Сама сборка работает на подчиненных устройствах, причем подчиненные устройства выполняются через SSH.
Я получаю сообщение об ошибке:
00:03:25.113 [codesign-app] build/App.app: User interaction is not allowed.
Я пробовал все предложения, которые я видел до сих пор в других сообщениях:
- Использование ключа разблокировки безопасности разблокировки непосредственно перед подписанием, чтобы разблокировать цепочку ключей.
- Перемещение ключа подписи в его собственную цепочку ключей.
- Перемещение ключа подписи в цепочку ключей входа в систему.
- Перемещение ключа подписи в системную цепочку ключей.
- Ручная настройка списка-цепочек ключей только к цепочке ключей, содержащей ключ.
Во всех случаях я получаю ту же ошибку.
В попытке диагностировать проблему я попытался запустить команду "разблокировать ключ безопасности" на моем локальном терминале и обнаружил, что она фактически не разблокирует цепочку ключей - если я смотрю в Keychain Access, символ блокировки по-прежнему там. В этом случае я передаю пароль в командной строке или могу ли я дать ему запрос на это. Разблокировка одной и той же брелка с помощью GUI подскажет мне пароль и затем разблокирует его. Кроме того, если я запустил "lock-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 на ведомой машине. Может быть, есть способ командной строки делать то, что запускает, когда вы запускаете "SessionCreate"?
Ответы
Ответ 1
Хорошо, я догадываюсь, что сегодня я могу ответить на свой собственный вопрос, потому что после того, как он ударил его в течение двух с половиной дней, одна из вещей, которые я пробовала, похоже, сработала. Я просто собираюсь отступить от него сейчас и надеюсь, что он продолжит работать.
По существу, похоже, что он доходит до -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"
Ответ 2
Я тоже борюсь с этим. Ничего не помогло, пока я не попробовал предложение http://devnet.jetbrains.com/thread/311971. Спасибо ashish agrawal!
Войдите в свой пользователь сборки через графический интерфейс и откройте доступ к Keychain. Выберите свой секретный ключ подписи, щелкните правой кнопкой мыши, выберите "Получить информацию", перейдите на вкладку "Контроль доступа" и выберите "Разрешить всем приложениям доступ к этому элементу".
![access control tab]()
Ответ 3
Ни один из других ответов не работал у меня.
В итоге меня спасло этот пост
Подводя итог, это может быть вызвано таймаутом по умолчанию в течение 5 минут, который вызовет эту ошибку после длинной сборки.
Чтобы исправить:
security set-keychain-settings -t 3600 -l ~/Library/Keychains/login.keychain
Ответ 4
Попробуйте вызвать security unlock-keychain
и codesign
как однострочную команду. Это помогло мне. Что-то вроде:
security unlock-keychain -p <password> /Users/<user>/Library/Keychains/login.keychain && codesign --force --verify --verbose --sign "<certificate id>" <app name>
Ответ 5
Поместите свои ключи в системный брелок
Ответ 6
Использование безопасности для создания брелка для /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}"
Это избыточно, если вы создали Keychain выше, но если Keychain уже существует, это необходимо.
Удалить значения по умолчанию из брелка
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, используя брелок для ключей. Который в случае apple-Tool:
требует apple:
и apple-Tool:
-s
относится к подписывающим сертификатам.
Gitlab-Runner, Дженкинс и тому подобное
Одна важная вещь для любого CI -T ype runner или build system - убедиться, что процесс запущен с launchd
правильно. Убедитесь, что ваш plist содержит <SessionCreate> </true>
.
Неправильное совпадение с владельцем связки ключей с процессом сборки и обеспечение создания сеанса безопасности приведет к возникновению всех видов головных болей. Диагностически вы можете ввести list-keychains
и посмотреть, соответствует ли результат вашим ожиданиям.
Это с man-страницы launchd.plist
:
SessionCreate <boolean>
Этот ключ указывает, что задание должно быть создано в новый сеанс аудита безопасности, а не сеанс по умолчанию для контекста. Подробнее см. В разделе "Аудион" (2).
UserName <string>
Этот необязательный ключ указывает, что пользователь должен выполнить задание как. Этот ключ применим только для служб, которые загружаются в привилегированный системный домен.
GroupName <string>
Этот необязательный ключ указывает группу для запуска задания как. Этот ключ применим только для служб, которые загружаются в привилегированный системный домен. Если UserName установлено, а GroupName - нет, то группа будет установлена в основную группу пользователя.
Наконец, код
Вы можете find-identity
хэширование сертификатов подписи с помощью find-identity
security find-identity -p codesigning -v
Кодифицировать структуру, 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.
Ответ 7
Итак, это команда, которая работает. -A
заключается в том, чтобы запретить Mac запрашивать пароль. Импорт в system.keychain не требует графического интерфейса.
sudo security import <cert.p12> -k "/Library/Keychains/System.keychain" -P <passphrase> -A
Ответ 8
Мой брелок был заблокирован. Он сопротивлялся, мой прогресс в изменении этого факта...
Keychain Access
→ Keychain First Aid
→ Repair
, et voilá!
Ответ 9
Разблокировать брелок недостаточно. Вы также должны установить для доступа к закрытому ключу "Разрешить всем приложениям доступ к этому элементу". И для этого из командной строки требуется повторно импортировать ключ. Итак, чтобы принимать вещи за раз:
Разблокируйте логин-логин, если он заблокирован. Однако он не должен быть заблокирован, но в любом случае, как вы это делаете:
security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "~/Library/Keychains/login.keychain"
Если по какой-то причине ваша машина сборки заблокирована логин-логин, и вы не хотите раскрывать этот пароль в script, тогда вы должны использовать другую цепочку ключей. Вы можете создать его на месте и использовать его в предыдущей и следующей команде. Чтобы создать его на месте:
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 - это то, что сделает ваш секретный ключ равным "Разрешить всем приложениям доступ к этому элементу"
Таким образом, используя все это, вы сможете сделать script, который устанавливает требуемый сертификат для создания выпуска ipa и подписывает его без подсказки. Вы можете сохранить файл .p12 в своем репо, так что любой компьютер может построить ваш ipa, не требуя ручной настройки.
Ответ 10
Импортируйте ключи в системную цепочку ключей. Вы можете использовать эту команду:
sudo security import YourKey.p12 -k /Library/Keychains/System.keychain -P PasswordToYourKey -T /usr/bin/codesign
Ответ 11
Итак, я пробовал каждый ответ здесь, и что-то не совсем складывалось. Наконец, я понял, когда перезагрузил свой CI-сервис, он работал под другим пользователем, чем я ожидал. Изменение для пользователя, на самом деле имевшего доступ к ключу в своей цепочке входа, все-таки зафиксировало. Это может не быть общей проблемой, но хотелось бы документировать мою конкретную причину этой ошибки, если это случается с другими.
Ответ 12
Для меня ничего не работало, похоже, придется переустанавливать Xcode снова и снова. Дженкинс продолжает давать ту же ошибку.
Вы бы сэкономили много времени, если просто переместите установку Xcode в корзину и переустановите. Убедитесь, что вы запускаете команду codeign из командной строки по крайней мере один раз.
Даже если вы получите ту же ошибку, попробуйте установить "Разблокировать брелок"? свойство в Jenkins и указать путь к вашему login.keychain под /Users/ ${USER}/Library/Keychains/login.keychain
Я надеюсь, что с вами это будет после этого.
Ответ 13
В моем случае это было вызвано созданием связки ключей с тайм-аутом по умолчанию 300 с и компиляцией длинных хкодов продолжительностью более 300 с. Обходной путь для меня заключался в следующем:
security set-keychain-settings -t <longer timeout in seconds> <keychain>
сразу после создания временной брелка.
Ответ 14
Я просмотрел все эти предложения и все еще испытывал проблемы с использованием fastlane gym
в задании Дженкинса. У меня был установлен сертификат, а keychain разблокирован и смог кодовое имя на подчиненном устройстве, когда я вручную выполнил команду codeign в командной строке.
В качестве обходного пути, если Jenkins подключается к подчиненному с помощью JNLP вместо SSH, вы сможете кодировать код.
Ответ 15
Для меня это происходит, когда второй брелок добавляется вручную и блокируется. По какой-то причине codesign
пытается получить доступ к заблокированной цепочке ключей и не удается, даже несмотря на то, что сертификаты находятся в логической цепочке (и разблокированы). Разблокирование второго разрешает проблему. Просто не имеет смысла для меня.
Ответ 16
Помимо разблокировки цепочки для ключей (как упоминалось в других ответах), вам необходимо разрешить доступ всех приложений к токену аутентификации XCode в цепочке для ключей:
- Выберите брелок для входа в систему
- Выберите категорию "Все предметы"
- Поиск по ключевому слову "xcode"
- Выберите "Разрешить всем приложениям доступ к этому элементу" для всех токенов Xcode
- Не забудьте добавить шаг разблокировки цепочки для ключей (из предыдущих ответов)
![Screenshot]()
Ответ 17
Попробуйте несколько вышеупомянутых решений. Я понял, что один из факторов, который у меня был, состоял в том, что я начал сборку с помощью консоли ION. Когда я переключился на создание сборки из приложения Terminal, все сработало отлично.