"Взаимодействие с пользователем не разрешено", пытаясь подписать приложение 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 AccessKeychain First AidRepair, 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, все сработало отлично.