Xcode 6 sets hidden "RemoveHeadersOnCopy" attribute for frameworks added to Copy Frameworks build phase, which is not reflected in the UI
| Originator: | jum | ||
| Number: | rdar://19794988 | Date Originated: | 11-Feb-2015 12:33 PM |
| Status: | Open | Resolved: | |
| Product: | Developer Tools | Product Version: | Xcode 6.1 |
| Classification: | Other Bug | Reproducible: | Always |
Summary: We embed a framework in our apps that is already signed by the framework vendor (with a certificate that is valid for our non-AppStore application). We thus wanted to keep the vendor signature instead of re-codesigning the framework with our certificate. However, when I added this framework to the copy frameworks build phase in our application’s target, I ended up with an application package that was rejected by spctl because („some sealed resources are missing“). Interestingly, „codesign -v“ did not flag this for the application package, but it turned out that the headers from the embedded framework were missing. Originally, I figured I’d have to leave the „sign on copy“ checkbox signed in order to get things working, but when I verified my changes before committing the project changes to SCM, I noticed there is another attribute for the copied framework, named „RemoveHeadersOnCopy“, which apparently was set when I added the framework to the copy files build phase in Xcode 6. Unfortunately, this flag is not reflected in Xcode’s UI, so it may really, really confuse developers that are trying to find out what is corrupting their application bundles… (In this specific case, it was the HockeyApp framework, but the same issue might happen for other pre-signed frameworks sold by 3rd party vendors.) Steps to Reproduce: Create application target, add signed framework (containing embedded headers) to copy files build phase; uncheck the „sign on copy“ Expected Results: Xcode should either leave the framework untouched, or indicate in the UI that the framework will be modified and the code-signature will break. Ideally, it would have a checkbox that allows to toggle the state of the „RemoveHeadersOnCopy“ attribute. In addition, it should display a warning that an existing code-signature will be broken when „RemoveHeadersOnCopy“ is enabled, but „SignOnCopy“ is disabled. Actual Results: Xcode „silently“ removed the headers from the framework during the copy build phase, which broke the code signature. No warning was shown in the UI or when building that the code signature will be broken due to the copy phase stripping the headers, but the „sign on copy“ checkbox being disabled. This left me with an invalid signature of my application package (actually of the embedded framework), which caused gatekeeper to reject the app. Regression: This did not happen in Xcode 5 or before. Also, projects created by Xcode 5 or earlier will not exhibit this problem unless new frameworks are added to the copy files build phase (which makes things worse, since it will appear to work for some frameworks, but not for others - depending on which version of Xcode was used to add them to the copy files build phase).
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!
My reply to the above remark by Apple Developer Relations
I don't consider this issue as resolved: While I can understand your point about removing headers and re-signing the framework, there's still the issue that just disabling the "Sign on Copy" checkbox for a copied framework will silently cause the app's code signature to break in a way that is not easy to detect, won't be flagged by Xcode and there is no visible hint in the Xcode UI that headers are going to be stripped from the framework.
IMHO, you need to either (a) enforce re-signing frameworks (in which case the "Sign on Copy" checkbox is moot) or (b) at least indicate in the UI that headers will be stripped and the framework's code signature will be invalidated when disabling the "Sign on Copy" checkbox
The way it is right now, any framework (with headers) that I add to a Copy Files build phase will not retain a valid signature and there is no way to keep that valid signature intact and there is not even an indication that this might happen. Also, since existing Copy Files entries that have been added to the build phase before Xcode 6 will not have the "RemoveHeadersOnCopy" attribute, things get really, really confusing, since some frameworks will get their signature invalidated, whereas others won't...
Apple Developer Relations on 25-Feb-2015 06:49 PM
If you are shipping a framework with your application, you shouldn't ship headers; they're not needed by the running application. And you should re-sign the framework to verify that this copy of the framework is what you intended to ship with your app. So I don't think you should disable RemoveHeadersOnCopy. If you did really need a workaround to do so, there exists one, but it sounds like you should be resigning instead.