向 Appstore/iTunesConnect 提交 Ad-hoc 应用程序 [英] Submitting Ad-hoc app to Appstore / iTunesConnect
问题描述
我知道如何使用 Appstore 移动设置签署应用程序，以及如何使用 Appstore 移动设置重新签署临时签名的 IPA.这不是我的问题.
I know how to sign an app with Appstore mobile provision, and how to re-sign an Adhoc-signed IPA with Appstore mobile provision. This is not my question.
我的问题是，您能否提交 Adhoc 签名的 IPA 到 Appstore/iTunesConnect，并让它通过 Apple 验证并最终通过 Appstore 分发.为什么?这样我就不必在每个 Adhoc 签名的候选版本 IPA 中存储一个冗余的 Appstore 签名的 IPA，也不必执行需要 Mac 机器重新签名的额外步骤.
My question is, can you submit Adhoc-signed IPA to Appstore / iTunesConnect, and have it pass Apple verification and eventually be distributed through Appstore. Why? So that I don't have to store a redundant Appstore-signed IPA along every Adhoc-signed release candidate IPA, and don't have to do the extra step of re-signing that requires a Mac machine.
当使用Application Loader时，它能够找到所有愚蠢的小错误，比如缺少图标和启动图像，但即使我通过Application Loader上传临时签名的IPA，它不会抱怨非应用商店移动提供(这很容易验证，就像图标一样).
When using Application Loader, it is able to find all the stupid little errors, like missing icons and launch images, but even when I upload Adhoc-signed IPA through Application Loader, it doesn't complain about non-appstore mobile provision (which is very easy to verify, just like icons).
我在测试中还发现，当您使用 Appstore 签名的 IPA(除非通过 Appstore 分发，否则您不应该在设备上安装)，可以将其安装在测试设备上，前提是设备上已经有 Adhoc 配置文件(相同的 AppID，相同的分发证书).
I have also found out in my testing, that when you take an Appstore-signed IPA (which you are not supposed to be able to install on devices unless distributed through Appstore), it is possible to install it on testing devices, provided the device already has Adhoc provision profile on it (same AppID, same distribution cert).
所以，这让我觉得 Apple 在通过 Appstore 分发时只是去掉了移动设备.
So, this makes me think Apple just strips out mobile provision when distributing through Appstore.
大约 3 年前有一个类似的问题(已关闭)，但如果它确实有效，OP 从未提供答案:使用临时配置文件将应用提交到应用商店.
There was a similar question (closed) from almost 3 years ago, but the OP never provided an answer if it had actually worked: Submitted app to appstore with adhoc profile.
我希望从那时起有人实际尝试过，证实了结果.
I hope someone since then had actually tried with it confirmed results.
推荐答案
在你的主要问题中有一些有针对性的内在问题，我会在我们进行时注意每个部分 - 一如既往，我会很高兴修改或澄清我是否遗漏了什么.我想这只是一个严密保密的秘密，因为它工作的大部分原因都可以追溯到作为支持 Apple 供应的公钥基础设施系统的功能的加密细节——这些东西变得很快，所以一些人认为它是[黑暗魔法.希望这能说明正在发生的事情！
There are a few targeted inner questions within your main question, I'll call attention to each part as we go -- as always, I'll be happy to revise or clarify if I miss something. I suppose it is only a closely guarded secret because much of the reasoning for it working come back to cryptographic details as a function of the Public Key Infrastructure system that backs Apple's provisioning -- This stuff gets deep fast so it is considered by some to be [dark] magic. Hopefully this will shine some light on what is going on!
TL;DR 版本
是的，您可以，但从技术上讲，这是一个不受支持的用例，可能随时更改.这是有效的，因为 iTunes Connect 选择验证的信息不包括 App Store 和 AdHoc 分发配置文件之间的单一区分因素.由于这在技术上是不允许的配置，我主张至少有一个备份计划，因为 Apple 可能会随时更改 iTunes Connect 验证政策，以打破这种提交边缘情况.
Yes you can, but it is technically an unsupported use case that may change at any time. This works because what information iTunes Connect chooses to validate does not include the single differentiating factor between an App Store and AdHoc distribution provisioning profile. Since this is technically not a permitted configuration, I'd advocate for at least having a backup plan since Apple may change iTunes Connect validation policy at any time breaking this submission edge case.
现在对于好奇的人来说，这是故事的其余部分......
您能否将 Adhoc 签名的 IPA 提交到 Appstore/iTunesConnect，并使其通过 Apple 验证并最终通过 Appstore 分发[?]
从 iTunesConnect 和应用程序加载器的这个特定迭代开始(2014 年 9 月 4 日/Xcode 5.1.1)，是的，您可以提交一个 AdHoc 签名的构建并通过管道接受它.眼尖的读者会注意到我的是"带有一个内置的逃生舱——因为 AdHoc 与 App Store 配置文件中编码的数据几乎相同，再加上 iTunesConnect 实际使用这些文件的哪些部分进行验证，AdHoc 配置文件以与同一应用的 AppStore 版本相同的方式呈现给交付管道.
As of this specific iteration of iTunesConnect and the Application Loader (4 Sept 2014 / Xcode 5.1.1), yes you can submit an AdHoc signed build and have it accepted through the pipeline. The eagle-eyed reader will note that my 'Yes' comes with a built-in escape hatch -- Because of the data encoded in AdHoc vs App Store provisioning profiles is nearly identical coupled with what parts of these files iTunesConnect is actually using for validation, an AdHoc provisioning profile presents to the delivery pipeline in the same manner as the AppStore version of the same app.
如果 AdHoc 和 App Store 文件之间的配置格式发生变化以明确区分两种类型的分发配置文件，或者 Apple iTunesConnect 工程师更改服务器端验证规则，这种未记录的行为很可能会停止工作.当然，我们都知道我们应该使用 App Store 配置文件，根据 App Distribution Guide > Submitting Your App > About Store Provisioning Profiles (https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/SubmittingYourApp/SubmittingYourApp.html#//apple_ref/doc/uid/TP40012582-CH9-SW32)[强调]:
Should the provisioning format change between AdHoc and App Store files to explicitly differentiate the two types of Distribution provisioning profiles or should Apple iTunesConnect engineers change server-side validation rules, it is distinctly possible that this undocumented behavior will stop working. Of course we all know that we are supposed to use the App Store provisioning profile, as per Developer documentation in the App Distribution Guide > Submitting Your App > About Store Provisioning Profiles (https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/SubmittingYourApp/SubmittingYourApp.html#//apple_ref/doc/uid/TP40012582-CH9-SW32) [emphasis added]:
商店分发配置文件包含一个与您的一个或多个应用相匹配的应用 ID，以及一个分发证书.对于 iOS 应用，您需要一个商店配置文件来提交您的应用.
A store distribution provisioning profile contains a single App ID that matches one or more of your apps, and a distribution certificate. For iOS apps, you need a store provisioning profile to submit your app.
...但这条其他途径目前有效.如果您确实选择使用此途径，您只需要注意这不是记录在案的行为，因此可能会随时更改，可能不会提前通知.由于它绕过了提交要求的边缘，因此至少为 Apple 更改配置或 iTC 验证要求的情况设置备份计划可能会很好——墨菲定律将规定这些验证更改将在最不合时宜的时间发生.
...but this other avenue works for now. If you do choose to use this avenue, you just need to be aware that it is not the documented behavior and thus would be subject to change at any point in time, likely without advanced notice. Since it is skirting the edges of submission requirements it would probably be good to at least have a backup plan setup for the case of Apple changing provisioning or iTC validation requirements -- Murphy's law would dictate that these validation changes would happen at the most inopportune time.
离开最佳实践"Soapbox，转向技术方面...
Stepping off the 'Best Practice' Soapbox and turning to the technical side of things...
为什么[这样做有效]?
您可能知道也可能不知道，配置文件恰好由 1 个 appId、一个或多个签名证书以及零个或多个测试设备组成.
As you may or may not know, provisioning profiles are composed of exactly 1 appId, one or more signing certificates, and zero or more test devices.
相关阅读:我对什么是代码签名身份? 更详细地说明了代码签名流程的各个部分.
Related Reading: I've got a longer answer to What are code signing identities? that speaks in more detail to the parts of the codesign process.
在这种情况下，问题是当文档说您需要拥有 App Store 配置文件时，为什么 AdHoc 配置文件有效?"
In this case the question is 'why do AdHoc profiles work when the documentation says you need to have an App Store profile?'
配置文件的内容包含一个加密签名的 .plist，其中包括上述信息，以及一些额外的元数据.在 OS X 机器上，您可以打开终端并运行:
The guts of a provisioning profile contain a cryptographically signed .plist that includes the information identified above, plus some additional metadata. On an OS X machine you can open Terminal and run:
security cms -D -i path/to/AdHoc.mobileprovision
...并在单独的终端窗口中运行等效的 App Store 配置文件:
...and in a separate Terminal window run the App Store profile equivalent:
security cms -D -i path/to/AppStore.mobileprovison
这些命令会将配置文件的 plist 部分转储到各自的终端窗口.当您滚动浏览两个窗口的内容时，您会注意到以下部分是相同的:
These commands will dump out the plist portion of the provisioning profile to their respective Terminal windows. When you scroll through the contents of both windows you will note that the following sections are identical:
- 应用 ID 名称
- AppliationIdentifierPrefix
- 开发者证书
- 权利
- 团队标识符
- 版本
个人资料的元数据不同，但这些完全是预期的差异，仅对验证个人资料有效性或询问个人资料的人有影响:
The profile's metadata are different, but those are entirely expected differences that only matter for validating profile validity, or for humans interrogating the profile:
- 创建日期
- 到期日期
- 姓名
- 生存时间
- UUID
需要注意的要点是:
DeveloperCertificates块在两个配置文件之间相同.- AdHoc 配置文件仅添加信息(
ProvisionedDevices)到 App Store 配置文件的结构和格式.
- The
DeveloperCertificatesblocks are identical between both profiles. - The AdHoc profile only adds information (
ProvisionedDevices) to the structure and format of the App Store profile.
DeveloperCertificates 数组的内容是 DER 编码的 X.509 iPhone 分发证书——与钥匙串中的完全相同.需要注意的是，此 DER 数据只是您的分发证书公私钥对的公共部分，并且只能被其他人用来验证来自您的应用程序签名——它可以不用于像你一样辞职二进制文件.
The contents of the DeveloperCertificates array is the DER encoded X.509 iPhone Distribution Certificate -- The exact same as the one in your keychain. Is is important to note that this DER data is only the public portion of your Distribution certificate public-private keypair, and it can only be used by others to authenticate the application's signature came from you -- It can not be used to resign a binary as you.
如果您将 DeveloperCertificates:Array:Data 元素的内容粘贴到 ASN.1 解码器 (http://lapo.it/asn1js/) 并将输出的元素与包含在钥匙串中的分发证书中编码的信息进行比较，您会发现它是公共分发的精确副本通过证书、标识符和配置文件工具提交证书签名请求后从 Apple 下载的证书.
If you paste the contents of DeveloperCertificates:Array:Data element into an ASN.1 decoder (http://lapo.it/asn1js/) and compare the elements of the output to the information encoded in the Distribution certificate included in the Keychain, you'll find that it is an exact copy of the public Distribution certificate you downloaded from Apple after submitting your Certificate Signing Request though the Certificates, Identifiers, and Profiles tool.
由于 AdHoc 和 App Store 配置文件使用相同的公钥证书作为其签名身份，因此它们在生成应用程序签名时本质上使用相同的私钥.这意味着使用 AdHoc 配置文件签名时生成的签名在功能上与使用 App Store 配置文件签名时生成的签名相同
Because both the AdHoc and App Store provisioning profiles use the same public key certificate as their signing identity, they are inherently using the same private key when generating the application's signature. This means that the signature generated when signing with an AdHoc profile is functionally identical to one generated when signing with the App Store profile
当 Apple 在提交过程中对 iTunes Connect 执行签名验证时，AdHoc 签名的加密签名和 App Store 签名的加密签名将根据 Apple 存档的分发证书成功验证，因为这两个配置文件都由相同的配置文件支持分发证书.
When Apple performs a signature validation on iTunes Connect during the submission process, both and AdHoc signed cryptographic signature and an App Store signed cryptographic signature will successfully validate against the Distribution Certificate Apple has on file as both provisioning profiles are backed by the same Distribution Certificate.
所以签名匹配，但为什么 AdHoc 配置文件中的额外信息不会阻止提交?
您最初的问题表明您熟悉 iOS 的应用安装政策.为了将来偶然发现此答案的人的利益，我将简要总结一下:
Your original question suggests that you have familiarity with iOS' app install policies. For the benefit of someone stumbling across this answer in the future I'll briefly summarize:
iOS 遵循拒绝一切，除非特别允许"的政策.也就是说，除非允许特定的授权"，否则 iOS 假定您不得安装应用程序.对于来自 App Store 的设备，应用程序的签名包括 Apple 的 App Store 身份，iOS 对此具有特定的授予"权限.AdHoc 安装默认属于拒绝"政策，Development 或 AdHoc 配置文件的 ProvisionedDevices 部分是特定的授予"权限.如果满足以下所有条件，该应用将在 App Store 之外安装:
iOS operates on a 'deny-all unless specifically permitted' policy. That is, iOS assumes you are not allowed to install an app unless a specific 'grant' has been allowed. For devices coming from the App Store, the app's signature includes Apple's App Store identity for which iOS has a specific 'grant' privilege. AdHoc installs by default fall under the 'deny' policy and the ProvisionedDevices section of a Development or AdHoc profile are the specific 'grant' privileges. The app will install outside of the App Store if all of the following hold true:
- 应用程序的加密签名有效
- 应用程序的嵌入式配置文件的加密签名仍然有效(配置文件未被篡改)
- 应用程序的嵌入式配置文件的
ExpirationDate尚未过去，并且当前时间不在CreationDate之前 - 嵌入的配置文件或安装到设备的配置文件与建议安装的 AppId 匹配.
- 嵌入的配置文件或安装到设备的配置文件在
ProvisionedDevices中包含一个与设备的 UDID 完全匹配的条目.
- The application's cryptographic signature is valid
- The application's embedded provisioning profile's cryptographic signature is still valid (the profile hasn't been tampered with)
- The application's embedded provisioning profile's
ExpirationDatehasn't passed and the current time isn't before theCreationDate - The embedded profile or a profile installed to the device match the AppId being proposed for installation.
- The embedded profile or a profile installed to the device contain an entry in
ProvisionedDevicesthat exactly match the device's UDID.
正如我们在上面看到的，App Store 配置文件和 Ad Hoc 配置文件之间的应用身份和签名信息是相同的——添加 ProvisionedDevices 仅用于添加这些授予"权限外部(App Store 之外)分发机制.事实证明，iTunes Connect/Application Loader 验证目前仅验证 Distribution 配置文件用于应用程序的签名，而不是使用的配置文件是 App Store 配置文件而不是 AdHoc 配置文件.
As we saw above, the app identity and signing information is identical between an App Store profile and and Ad Hoc profile -- the addition of ProvisionedDevices serves only to add these 'grant' privileges for an external (outside of App Store) distribution mechanism. It turns out that iTunes Connect / Application Loader validation is currently only validating that a Distribution profile was used for the app's signature, not that the profile that was used was an App Store profile instead of an AdHoc profile.
这归结为这样一个事实，即从版本 1 开始(在 plist 中的ala Version 块)，AdHoc 和 App Store 分发配置文件之间的唯一区别因素是 ProvisionedDevices 块.事实证明，截至今天，这不是 Apple 在查询所使用的配置文件时要查找的细节，因此二进制文件通过了应用验证的自动化部分.他们肯定会检查配置文件中的 AppId 是否与应用程序声明的内容相匹配，签名身份是否与用于签署二进制文件的内容、到期日期和使用的任何权利相匹配，此外到您在原始问题中突出显示的项目(iTunes Connect 和 info.plist 之间的版本检查、图标存在、图标大小等)
This boils down to the fact that the as of Version 1 (ala Version block in the plist) the only differentiating factor between AdHoc and App Store distribution profiles is the presence or absence of the ProvisionedDevices block. It turns out that as of today, this is not a detail that Apple looks for when interrogating the profile that was used, thus the binary passes the automated portions of app verification. They definitely do check that the AppId in the profile matches what the App claims, that the signing identity matches what was used to sign the binary, expiration dates, and any entitlements used match what is found in the automated scan of the app, in addition to the items you highlighted in your original question (version checks between iTunes Connect and the info.plist, iconography presence, iconography sizes, etc.)
假设，在随后的 iTunes Connect/Application Loader 更新中，他们可以开始检查提交的文件中存在的 embedded.mobileprovision 配置文件中是否缺少此密钥二进制文件，并以未使用 App Store 配置文件为由自动拒绝提交.类似地，如果配置文件格式已更新(例如 Version=2)，他们可以添加一个新元素，明确调用配置文件的类型，如果它不是 App Store 类型，则自动拒绝.它可能看起来像这样:
Hypothetically, in a subsequent iTunes Connect / Application Loader update, they could start checking for the absence of this key in the embedded.mobileprovision profile that exists within the submitted binary and auto-reject the submission on the grounds that an App Store profile was not used. Similarly, if the provisioning profile format was updated (ex. Version=2) they could add a new element that explicitly calls out the type of profile and auto-reject if it isn't an App Store type. It could perhaps look like this:
<key>ProfileType</key>
<integer>1</integer>
其中整数值可以是 1、2 或 3，具体取决于使用的配置文件类型，与 Info.plist 等用于识别支持的设备系列(仅限 iPhone、仅限 iPad 或普遍的).这将澄清有关确定构建类型的其他问题.
Where the integer value could be 1, 2 or, 3 depending on the type of profile in use, consistent with the formats used in things like Info.plist for identifying supported device families (iPhone-only, iPad-only, or Universal). This would clarify other questions that have been asked about identifying the type of build.
相关阅读:
所以，这让我觉得 Apple 在通过 Appstore 分发时只是去掉了移动设备.
是的！如果您查看您提交的应用程序的存档版本，您会发现该应用程序的内容包含 embedded.mobileprovision -- 如果您随后从 App Store 下载相同版本，您将发现那个文件不见了.Apple 仅在提交和审核过程中使用 embedding.mobileprovision 来验证您的应用程序的内容.当应用程序处于为 App Store 处理"状态时，最终的包被组装，嵌入的配置文件被删除.
Yes they do! If you look at archived versions of the apps you submitted you'll find that the contents of the app contain embedded.mobileprovision -- if you then go download the same version from the App Store, you'll find that file missing. Apple only uses embedded.mobileprovision to verify the contents of your app during the submission and review process. When the app is 'Processing for App Store' the final package is assembled and the embedded profile is removed.
这篇关于向 Appstore/iTunesConnect 提交 Ad-hoc 应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
