Загрузка сборки, подписанной ботом Xcode, в testflight отклонена из-за ошибки get-task-allow

Question

При попытке загрузить подписанный файл.ipa, созданный ботом Xcode, в TestFlight, я получил стандарт

"Недопустимый IPA: значения get-task-allow во встроенном.mobileprovision и в вашем двоичном файле не совпадают. Вы уверены, что создали IPA с тем же типом сертификата, который использовался для его компиляции?"

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

• Мой бот использует схему сборки, которая настроена на использование конфигурации Ad-Hoc при архивировании.
• Моя конфигурация Ad-Hoc является дубликатом моей конфигурации Release, за исключением...
• Идентификатор подписи кода явно установлен для сертификата распространения для учетной записи этого приложения.

Когда я распаковываю.ipa, а затем запускаю codesign -d -vvvv /path/to/The.app, это подтверждает, что приложение было подписано с использованием соответствующего сертификата распространения. Я также могу использовать супер-полезный плагин быстрого просмотра Craig Hockenberry, чтобы подтвердить, что embedded.mobileprovision является подходящим профильным профилем обеспечения.

Супер-странная / расстраивающая часть - если я скачаю.xcarchive, созданный ботом, а затем подпишу его двойным щелчком, а затем, пройдя через традиционную кнопку "Распределить..." в органайзере, он загрузит в TestFlight без заминок.

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

Документация Apple по подписанию кода (прокрутите вниз до "Code Hash"), похоже, указывает на то, что несовпадающие хеши могут означать, что что-то пошло не так:

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

У кого-нибудь есть смутное представление, что это может быть? Архив, который я использую для создания.ipa, который работает, загружается прямо из той же папки с продуктами сборки, что и.ipa, который не работает, поэтому, если я правильно понимаю эту документацию, хэши должны быть идентичны. Или я неправильно понимаю, что документация и что-то еще пошло не так?

Обновление 12/30: еще одна вещь, которую я понял после того, как друг предложил попробовать: продукт для сборки, поступающий непосредственно от Xcode Bot, устанавливается непосредственно на мой телефон (который находится в рассматриваемом профиле обеспечения) через Xcode Organizer без проблем. По их запросу я отправил сборки TestFlight по электронной почте, и они выясняют, могут ли они найти какие-либо проблемы с их стороны.

Обновление 2, 12/30: отмечу, что этот сценарий от Мэтта Власача действительно работает, но на самом деле он переподписывает приложение из архива с сертификатом и профилем обеспечения - теоретически не нужно добавлять этот шаг если сертификат и профиль обеспечения совпадают с теми, которые указаны в вашей схеме сборки, можно просто загрузить продукт сборки.ipa напрямую. Мэтт не вдавался в подробности о том, почему он добавил этот шаг в свой пост - у кого-нибудь есть мысли по этому поводу?

Обновление 3, 1/2: загадка углубляется: если я беру продукт сборки прямо из Xcode Bot и загружаю его с помощью приложения TestFlight для настольного компьютера, он загружается нормально, устанавливается на мой телефон (который находится в профиле обеспечения) нормально и открывается и прекрасно работает после установки. Я отправил в службу поддержки TestFlight кучу журналов об этом по их запросу, они собираются взглянуть на происходящее wtfbbq, и я сообщу, когда получу от них ответ.

Answer 1

Woo!

24 января 2014 в 16:39 Поддержка PST TestFlight пишет:

Привет Эллен,

Наша команда установила исправление для этой проблемы.

Пожалуйста, дайте нам знать, если у вас возникнут проблемы.

Сегодня утром я подтвердил, что мои сборки, которые ранее были отклонены на get-task-allow вопрос сейчас загружаю счастливо. Если у вас все еще есть проблемы, и вы пробовали все вышеописанные шаги, я настоятельно рекомендую обратиться непосредственно в службу поддержки TestFlight, они очень полезны.

Answer 2

Я недавно получил эту проблему и строил по командной строке. Я понял, что команда xcodebuild выберет профили обеспечения и подписи willynilly. Затем, если вы подписали скомпилированную папку с помощью xcrun и PackageApplication, она может подписать ее с другим профилем sig или предоставлением.

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

Это то, что было раньше, за исключением последующего вызова xcrun для подписи и упаковки приложения. xcodebuild -sdk iphoneos -configuration Release

Это то, что требовалось xcodebuild -sdk iphoneos -configuration Release CODE_SIGN_IDENTITY= PROVISIONING_PROFILE=

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