Отправка специального приложения в Appstore / iTunesConnect

Question

Я знаю, как подписать приложение с помощью мобильного обеспечения Appstore и как заново подписать подписанное Adhoc IPA с помощью мобильного предложения Appstore. Это не мой вопрос.

Мой вопрос заключается в том, можете ли вы отправить подписанное Adhoc IPA в Appstore / iTunesConnect и передать его Apple для проверки и в конечном итоге распространить через Appstore. Зачем? Так что мне не нужно хранить избыточный IPA с подписью Appstore на каждом IPA-кандидате с подписью Adhoc и не нужно делать дополнительный шаг повторной подписи, который требует компьютер Mac.

При использовании Application Loader он может обнаружить все глупые маленькие ошибки, такие как отсутствующие значки и образы запуска, но даже когда я загружаю подписанный Adhoc IPA через Application Loader, он не жалуется на мобильное обеспечение не в AppStore (которое очень легко проверить, так же, как значки).

В ходе тестирования я также обнаружил, что когда вы берете IPA, подписанный Appstore (который вы не должны устанавливать на устройства, если он не распространяется через Appstore), его можно установить на тестовые устройства при условии, что устройство на нем уже есть профиль обеспечения Adhoc (тот же AppID, тот же сертификат распространения).

Таким образом, это заставляет меня думать, что Apple просто удаляет мобильное обеспечение при распространении через Appstore.

Был похожий вопрос (закрыт) почти 3 года назад, но ОП никогда не давал ответа, если он действительно работал: отправил приложение в appstore с профилем adhoc.

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

Answer 1

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

TL; DR версия

Да, вы можете, но технически это неподдерживаемый вариант использования, который может измениться в любое время. Это работает, потому что информация, которую iTunes Connect выбирает для проверки, не включает в себя единый фактор различия между App Store и профилем обеспечения распространения AdHoc. Так как это технически недопустимая конфигурация, я бы рекомендовал, по крайней мере, иметь план резервного копирования, так как Apple может изменить политику проверки iTunes Connect в любое время, нарушив этот крайний случай отправки.

Теперь для любопытных, вот остальная часть истории...

Можете ли вы отправить подписанное Adhoc IPA в Appstore / iTunesConnect и пройти проверку Apple и в конечном итоге распространить через Appstore[?]

Начиная с этой конкретной итерации iTunesConnect и загрузчика приложений (4 сентября 2014 / Xcode 5.1.1), да, вы можете отправить подписанную сборку AdHoc и принять ее через конвейер. Читатель с орлиными глазами заметит, что мое "Да" поставляется со встроенным аварийным люком - поскольку данные, закодированные в профилях обеспечения AdHoc vs App Store, практически идентичны в сочетании с тем, какие части этих файлов iTunesConnect фактически использует для проверки профиль обеспечения AdHoc представляет конвейеру доставки так же, как и версия AppStore того же приложения.

Если формат обеспечения изменяется между файлами AdHoc и App Store для явной дифференциации двух типов профилей обеспечения распространения или если инженеры Apple iTunesConnect изменяют правила проверки на стороне сервера, вполне вероятно, что это недокументированное поведение перестанет работать. Конечно, мы все знаем, что мы должны использовать профиль обеспечения App Store в соответствии с документацией разработчика в Руководстве по распространению приложений> Отправка приложения> О профилях обеспечения Store ( https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/SubmittingYourApp/SubmittingYourApp.html) [выделение добавлено]:

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

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

Сойдя с мыльницы "Best Practice" и перейдя к технической стороне вещей...

Почему [это работает]?

Как вы можете знать или не знать, профили обеспечения состоят из ровно 1 appId, одного или нескольких сертификатов подписи и нуля или более тестовых устройств.

Связанное Чтение: у меня есть более длинный ответ на Что такое идентификаторы подписи кода? это говорит более подробно с частями процесса кодирования.

В этом случае возникает вопрос: "Почему работают профили AdHoc, если в документации сказано, что вам нужен профиль в App Store?".

Внутренности профиля обеспечения содержат криптографически подписанный.plist, который включает информацию, указанную выше, плюс некоторые дополнительные метаданные. На компьютере с OS X вы можете открыть терминал и запустить:

security cms -D -i path/to/AdHoc.mobileprovision

... и в отдельном окне терминала запустите эквивалент профиля App Store:

security cms -D -i path/to/AppStore.mobileprovison

Эти команды будут выгружать часть plist профиля обеспечения в соответствующие окна терминала. Прокручивая содержимое обоих окон, вы заметите, что следующие разделы идентичны:

• AppIDName
• AppliationIdentifierPrefix
• DeveloperCertificates
• Entitlements
• TeamIdentifier
• Версия

Метаданные профиля различны, но это полностью ожидаемые различия, которые имеют значение только для проверки достоверности профиля или для людей, запрашивающих профиль:

• Дата создания
• Дата окончания срока
• название
• Время жить
• UUID

Существенные моменты, чтобы забрать являются:

• DeveloperCertificates блоки идентичны между обоими профилями.
• Профиль AdHoc только добавляет информацию (ProvisionedDevices) к структуре и формату профиля App Store.

Содержание DeveloperCertificates массив представляет собой DER-кодированный сертификат распространения iPhone X.509 - точно такой же, как и в вашей цепочке для ключей. Важно отметить, что эти данные DER являются только общедоступной частью пары открытых и закрытых ключей вашего сертификата распространения и могут быть использованы только для проверки подлинности подписи приложения, полученной от вас. Их нельзя использовать для отставки двоичного файла. как и ты.

Если вы вставите содержимое DeveloperCertificates:Array:Data в декодер ASN.1 ( http://lapo.it/asn1js/) и сравните элементы вывода с информацией, закодированной в сертификате распределения, включенном в цепочку для ключей, вы обнаружите, что это точная копия общедоступного сертификата распространения, который вы скачали с Apple после отправки запроса на подпись сертификата с помощью инструмента "Сертификаты, идентификаторы и профили".

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

Когда Apple выполняет проверку подписи в iTunes Connect во время процесса отправки, криптографическая подпись, подписанная AdHoc, и криптографическая подпись App Store будут успешно проверены на соответствие сертификату распространения, который Apple хранит в файле, поскольку оба профиля обеспечения поддерживаются одним и тем же сертификатом распространения.

Таким образом, подписи совпадают, но почему дополнительная информация в профилях AdHoc не сработает при отправке?

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

iOS работает по принципу "запретить все, если не указано иное". То есть iOS предполагает, что вам не разрешено устанавливать приложение, если не разрешен определенный "грант". Для устройств, поступающих из App Store, подпись приложения включает в себя идентификатор Apple App Store, для которого у iOS есть особая привилегия "предоставить". Установки AdHoc по умолчанию подпадают под политику "запретить" и ProvisionedDevices раздел профиля разработки или AdHoc - это особые привилегии "предоставления". Приложение будет установлено за пределами App Store, если выполнено все следующее:

• Криптографическая подпись приложения действительна
• Криптографическая подпись встроенного профиля приложения приложения по-прежнему действительна (профиль не был подделан)
• Встроенный профиль обеспечения приложения ExpirationDate не прошло, и текущее время не раньше CreationDate
• Встроенный профиль или профиль, установленный на устройстве, соответствует идентификатору AppId, предлагаемому для установки.
• Встроенный профиль или профиль, установленный на устройстве, содержит запись в ProvisionedDevices это точно соответствует UDID устройства.

Как мы видели выше, идентичность приложения и информация о подписи идентичны между профилем App Store и специальным профилем - добавление ProvisionedDevices служит только для добавления этих привилегий "предоставления" для внешнего (вне App Store) механизма распространения. Оказывается, в настоящее время проверка iTunes Connect / Application Loader проверяет только то, что профиль подписи был использован для подписи приложения, а не то, что используемый профиль был профилем App Store, а не профилем AdHoc.

Это сводится к тому, что по состоянию на версии 1 (аля Version блок-лист) единственное различие между профилями рассылки AdHoc и App Store - это наличие или отсутствие ProvisionedDevices блок. Оказывается, что на сегодняшний день это не та деталь, которую Apple ищет при опросе используемого профиля, таким образом, двоичный файл проходит автоматические этапы проверки приложения. Они определенно проверяют, что AppId в профиле совпадает с заявленным приложением, что удостоверение подписи совпадает с тем, что использовалось для подписи двоичного файла, датами истечения срока действия и любыми используемыми разрешениями, что совпадает с тем, что обнаружено при автоматическом сканировании приложения. к элементам, выделенным в исходном вопросе (проверка версий между iTunes Connect и списком info.plist, наличием значков, размерами значков и т. д.)

Гипотетически, в последующем обновлении iTunes Connect / Application Loader они могли бы начать проверять отсутствие этого ключа в embedded.mobileprovision профиль, который существует в представленном двоичном файле и автоматически отклоняет отправку на том основании, что профиль App Store не использовался. Точно так же, если формат профиля обеспечения был обновлен (например, Version=2), они могли бы добавить новый элемент, который явно вызывает тип профиля, и автоматически отклонять его, если это не тип App Store. Это может выглядеть так:

<key>ProfileType</key>
<integer>1</integer>

Где целочисленное значение может быть 1, 2 или, 3, в зависимости от типа используемого профиля, в соответствии с форматами, используемыми в таких вещах, как Info.plist для идентификации поддерживаемых семейств устройств (только для iPhone, только для iPad или Universal). Это бы прояснило другие вопросы, которые задавались об определении типа сборки.

Связанное Чтение:

• Как определить, что профиль обеспечения предназначен для разработки или распространения программно
• Проверьте, является ли приложение ad-hoc | dev | app-store build во время выполнения

Таким образом, это заставляет меня думать, что Apple просто удаляет мобильное обеспечение при распространении через Appstore.

Да, они делают! Если вы посмотрите на архивные версии приложений, которые вы представили, то обнаружите, что содержимое приложения содержит embedded.mobileprovision - если вы затем загрузите ту же версию из App Store, вы обнаружите, что этот файл отсутствует. Apple использует EmbeddedMobileprovision только для проверки содержимого вашего приложения в процессе отправки и проверки. Когда приложение "Обрабатывается в App Store", окончательный пакет собирается и внедренный профиль удаляется.