"Взаимодействие с пользователем запрещено" попытка подписать приложение OSX с помощью codesign
наша автоматическая сборка работает на Дженкинсе. Сама сборка выполняется на рабах, при этом рабы выполняются через SSH.
Я получаю сообщение об ошибке:
00:03:25.113 [codesign-app] build/App.app: User interaction is not allowed.
Я пробовал все предложения, которые я видел до сих пор в других сообщениях здесь:
- использование разблокировки безопасности-брелок непосредственно перед подписанием, чтобы разблокировать брелок.
- перемещение ключа подписи в собственный брелок.
- перемещение ключа подписи в логин брелок.
- перемещение ключа подписи в систему брелок.
- настройка вручную-брелки только брелок, который содержит ключ.
во всех случаях я получаю ту же ошибку.
в попытке диагностировать проблему я попытался запустить команду "Security unlock-keychain" на моем локальном терминале и обнаружил, что на самом деле она не разблокирует keychain - если я посмотрю в Keychain Access, символ блокировки все еще там. Это дело передаю ли я пароль в командной строке или позволяю ему подсказать мне его. Разблокировка же брелок с помощью GUI предложит мне пароль, а затем разблокировать его. Кроме того, если я запускаю "security lock-keychain", я do посмотреть ключ сразу после выполнения команды. Это заставляет меня думать, что 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.
из этого, казалось бы, что list-keychains-это то, что не работает. Может быть, ни работать. :/
есть подобный вопрос здесь. Решение интересно-установите" SessionCreate " в true в launchctl. Но я не строю на master-мой процесс сборки запускается из SSH на подчиненной машине сборки. Возможно, есть способ командной строки сделать то, что делает launchctl когда вы запускаете "SessionCreate"?
16 ответов
Я тоже боролся с этим. Ничего не помогло, пока я не попробовал предложение на http://devnet.jetbrains.com/thread/311971. Спасибо ashish agrawal!
войдите в систему пользователя сборки через GUI и откройте доступ к связке ключей. Выберите закрытый ключ подписи, щелкните правой кнопкой мыши, выберите получить информацию, перейдите на вкладку Управление доступом и выберите "Разрешить всем приложениям доступ к этому элементу".
по существу, похоже, что это сводится к -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"
ни один из ответов работал для меня.
то, что в конечном итоге спасло меня, было этот пост
чтобы подвести итог, это может быть вызвано таймаутом по умолчанию 5 минут, который вызовет эту ошибку после долгой сборки.
исправления:
security set-keychain-settings -t 3600 -l ~/Library/Keychains/login.keychain
попробуйте позвонить security unlock-keychain
и codesign
как однострочная команда. Это помогло мне. Что-то вроде:
security unlock-keychain -p <password> /Users/<user>/Library/Keychains/login.keychain && codesign --force --verify --verbose --sign "<certificate id>" <app name>
Итак, это команда, которая работает. -A
, чтобы предотвратить Mac от запроса пароля. Импорт в систему.keychain не требует GUI.
sudo security import <cert.p12> -k "/Library/Keychains/System.keychain" -P <passphrase> -A
мой брелок был заперт. Это сопротивление мои достижения, чтобы изменить этот факт...
Keychain Access
->Keychain First Aid
->Repair
, et voilá!
разблокировка брелка недостаточно. Вы также должны установить доступ к закрытому ключу "разрешить всем приложениям доступ к этому элементу". И сделать это из командной строки требует импортировать ключ. Итак, чтобы взять вещи за раз:
разблокируйте брелок для входа, если он заблокирован. Он не должен быть заблокирован, но в любом случае вот как вы это делаете:
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 без необходимости ручной настройки.
импортируйте ключи в системный брелок. Вы можете использовать эту команду:
sudo security import YourKey.p12 -k /Library/Keychains/System.keychain -P PasswordToYourKey -T /usr/bin/codesign
для меня ничего не работало, кажется, придется переустановить Xcode снова и снова. Дженкинс продолжает давать ту же ошибку. Вы сэкономите много времени, если просто переместите установку Xcode в корзину и переустановите. Убедитесь, что вы запустите команду codesign из командной строки по крайней мере один раз.
даже после того, как вы получите ту же ошибку, попробуйте установить " разблокировать брелок?'собственность в пределах Дженкинса и дайте путь к вашему логину.keychain под /Users / ${USER} / библиотека / брелки / логин.брелок
Я надеюсь, что Бог быть с тобой После этого.
в моем случае это было вызвано созданием связки ключей с таймаутом по умолчанию 300s и длинной компиляцией xcode продолжительностью более 300s. Обходным путем для меня было вызвать:
security set-keychain-settings -t <longer timeout in seconds> <keychain>
сразу после создания временной связки ключей.
Я пробежал все эти предложения и все еще испытывал проблемы с использованием fastlane gym
в работе Дженкинс. Я установил сертификат и разблокировал брелок и смог codesign на ведомом устройстве, когда я вручную запустил команду codesign в командной строке.
в качестве обходного пути, если Дженкинс подключается к ведомому устройству с помощью JNLP вместо SSH, вы сможете codesign.
поэтому я попробовал каждый ответ здесь, и что-то не совсем складывалось. Наконец, я понял, когда я перезагрузил свою службу CI, она работала под другим пользователем, чем я ожидал. Изменение на пользователя, который фактически имел доступ к ключу в цепочке входа в систему, исправило все. Это не может быть общей проблемой, но я хотел бы документировать свою конкретную причину этой ошибки, если это произойдет с другими.
для меня это происходит, когда есть второй брелок, добавленный вручную, и он заблокирован. Почему-то codesign
пытается получить доступ к заблокированной связке ключей и терпит неудачу, даже если сертификаты находятся в связке ключей входа (и разблокированы). Разблокировка второй решает проблему. Просто не вижу смысла.
использование безопасности для создания связки ключей для/usr/bin / codesign
импорт сертификата и его программная работа с codesign-это не вопрос использования логина или системных ключей или молитвы какому-то Богу codesign. Вам просто нужно иметь правильные разрешения. Я рекомендую создать новый брелок специально для использования в Японии.
на codesign
не дает errSecInternalComponent
вам нужно получить список разделов (ACLs) правильно. Я пройду по ступенькам:--34-->
создать брелок
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}"
не указывая никаких аргументов, это установит тайм-аут автоматической блокировки на неограниченный и удалит автоматическую блокировку во время сна.
импортируйте сертификаты подписи из a .Р12
security import "${DIST_CER}" -P "${CERTIFICATE_PASSWORD}" -k "${KEYCHAIN_NAME}" -T /usr/bin/codesign
импорт сертификатов и дает codesign
открыть с помощью .
установите ACL на брелок
security set-key-partition-list -S apple-tool:,apple: -s -k "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"
это требование, которое многие люди пропускают. Вы можете увидеть, что macOS делает с помощью dump-keychain. Что в случае codesigning требует apple:
и apple-tool:
. -s
относится к подписанию сертификатов.
GitLab-Runner, Дженкинс и тому подобное
одна очень важная вещь для любого бегуна типа CI или системы сборки - убедиться, что процесс запущен из launchd
правильно. Убедитесь, что ваш plist содержит <SessionCreate> </true>
.
неправильное сопоставление владельца связки ключей с процессом сборки и убедитесь, что сеанс безопасности будет создан, приведет к всевозможным головным болям. Диагностически говоря, вы можете ввести list-keychains
и посмотреть, соответствует ли результат вашим ожиданиям.
это launchd.plist
man-page:
SessionCreate <boolean>
этот ключ указывает, что задание должно быть создано в новую безопасность аудит сеанс, а не сеанс по умолчанию для контекста принадлежит к. Увидеть аудитон(2) для деталей.
UserName <string>
этот необязательный ключ указывает пользователя для выполнения задания. Этот ключ только применимо для служб, загружаемых в привилегированную систему домен.
GroupName <string>
этот необязательный ключ указывает группу для выполнения задания как. Этот ключ только применимо для служб, загружаемых в привилегированную систему домен. Если имя пользователя установлено, а GroupName нет, то группа будет задайте основную группу пользователя.
наконец-то codesign
вы можете искать хэш сертификатов подписи, используя find-identity
security find-identity -p codesigning -v
бортовой рамки, dylib нужна и т. д.
/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" "$SIGNABLE"
Codesign пакет приложений
/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}
, где путь к платформе-каталог /usr/bin для данного целевого SDK, а TOOLCHAIN_PATH - /usr/bin для хост-инструментов Xcode.
после попытки ряда вышеуказанных решений. Я понял, что одним из факторов, который у меня был, было то, что я начинал сборку с помощью консоли ION. Когда я вернулся к созданию сборки из приложения терминала, все работало нормально.