Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code signing problems due to Apollo framework #14

Closed
stephensilber opened this issue Nov 5, 2016 · 16 comments
Closed

Code signing problems due to Apollo framework #14

stephensilber opened this issue Nov 5, 2016 · 16 comments

Comments

@stephensilber
Copy link

stephensilber commented Nov 5, 2016

I just finished debugging a bunch of problems I was having submitting a build to TestFlight, and the root of the cause seems to have been the check-and-run-apollo-codegen.sh file in the Apollo framework (installed via Cocoapods). I removed that file from the project and temporarily removed the run script from my own project build phases, and the code signing finally succeeded. Here is the error I got:

ERROR ITMS-90035: "Invalid Signature. Code object is not signed at all. Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose "Clean All" in Xcode, delete the "build" directory in the Finder, and rebuild your release target. For more information, please consult https://developer.apple.com/library/ios/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html"

Hopefully this will help any one else having this problem

@stubailo
Copy link
Contributor

stubailo commented Nov 7, 2016

Interesting, is there anything we can do to make this work out of the box?

@maxsz
Copy link
Contributor

maxsz commented Nov 9, 2016

@stephensilber What was wrong with the codesigning? Can you provide the output of codesign -dvvv <IPA>?

@stephensilber
Copy link
Author

I haven't had a chance to look into this, but I'll be submitting another build either today or tomorrow and will make note of anything that may be useful, including the output of codesign -dvvv <IPA>

@martijnwalraven
Copy link
Contributor

@stephensilber: Did you find out anything more about this?

@stephensilber
Copy link
Author

stephensilber commented Nov 18, 2016

@martijnwalraven to work around it, I have been manually removing the custom build phase run script and the check-and-run-apollo-codegen.sh script from the Apollo target before archiving. I just left both of those there to test this. I archived a build and then exported it as an IPA for distribution, and here's the ouput for the command you mentioned above:

➜  Verse 2016-11-18 12-32-28 codesign -dvvv Verse.ipa
Verse.ipa: code object is not signed at all

Sorry for the late response. Let me know what else I can help do to debug this on my end

@fruitcoder
Copy link

Holy ****. I was also fighting with codesigning today for a TestFlight submission and got the same error, which didn't give me any clue what was going wrong. I will try to remove the run script, but that's probably not sufficient. I'm using Carthage, so I really don't know how to automate this 🤔

@stephensilber
Copy link
Author

stephensilber commented Nov 21, 2016

Can that .sh script be moved into the build phase run script* so it's not a piece of
the Apollo project? Not the most ideal solution due to updates maybe needing
to change that script, but there could be a version check that points to an
updated script? Still somewhat manual, but only when the framework changes
the script.

**fixed some typos from posting this on mobile

On Mon, Nov 21, 2016 at 2:31 PM Alex Hüllmandel notifications@github.com
wrote:

Holy ****. I was also fighting with codesigning today for a TestFlight
submission and got the same error, which didn't give me any clue what was
going wrong. I will try to remove the run script, but that's probably not
sufficient. I'm using Carthage, so I really don't know how to automate this
🤔


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#14 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAzmuUa1SpUqetd1cnk08_QzXs3KdRxdks5rAfGpgaJpZM4KqTdI
.

@fruitcoder
Copy link

I'm still unsure how to tackle this and I have no reference project to look into.
Updating carthage, manually deleting the install-or-update-starwars-server.sh and copying check-and-run-apollo-codegen.sh over to my target + customizing the run script fixed the signing issue, but it's rather cumbersome.
Copying the script directly in the run script phase sounds like an idea, but didn't you also have to delete the install-or-update-starwars-server.sh to make signing work?

@maxsz
Copy link
Contributor

maxsz commented Nov 22, 2016

I think the correct way to not have check-and-run-apollo-codegen.sh added to the app bundle by cocoapods is to change the podspec from

[...]
s.resource = 'scripts/check-and-run-apollo-codegen.sh'
[...]

to

[...]
s.preserve_path = ''scripts/check-and-run-apollo-codegen.sh'
[...]

Thus preserving the check-and-run-apollo-codegen.sh file, so people can run it in a build phase, but not adding it to the target app bundle.

@stephensilber can you try that and see if it helps?

Update:
I've just created a new minimal test project with Apollo and there are no codesigning issues at all. I can't think of any reason why the check-and-run-apollo-codegen.sh script should break codesigning, it's just a resource in the framework, which is build before any codesigning steps.

The above comment is still valid, though, because I don't think we want to ship this script in the released app IPA.

@fruitcoder
Copy link

fruitcoder commented Nov 22, 2016

If the script wasn't in the targets I could also reference it through the Carthage/Checkouts directory without any extra setup after updating dependencies.

@martijnwalraven
Copy link
Contributor

I came across this, so it seems it is a known issue and affects other frameworks as well.

Not sure yet what the root cause is and whether there are any workarounds that don't involve removing the script from the bundle.

@fruitcoder
Copy link

Yeah, I read the same thing :)
In the end, I will have a custom action in fastlane that could remove the script before uploading to iTC, but we should look for a solution that works for everyone.

@nubbel
Copy link

nubbel commented Nov 22, 2016

Not sure about Carthage, but for Cocoapods the solution is what @maxsz suggested.
Using preserve_path instead of resource prevents that the script ends up in the bundle.

@fruitcoder
Copy link

Yeah, this definitely works for Cocoapods

@nubbel
Copy link

nubbel commented Nov 22, 2016

We've figured it out!
@maxsz is preparing a PR right now that fixes this issue for both Cocoapods and Carthage.

maxsz pushed a commit to equinux/apollo-ios that referenced this issue Nov 22, 2016
This fixes "Code signing problems due to Apollo framework apollographql#14" by not adding the `check-and-run-apollo-codegen.sh` script to the framework resources.
@maxsz maxsz mentioned this issue Nov 22, 2016
@maxsz
Copy link
Contributor

maxsz commented Nov 22, 2016

I've created a pull request which should fix this for Cocoapods and Carthage.

maxsz pushed a commit to equinux/apollo-ios that referenced this issue Nov 22, 2016
This fixes "Code signing problems due to Apollo framework apollographql#14" by not adding the `check-and-run-apollo-codegen.sh` script to the framework resources.
martijnwalraven added a commit that referenced this issue Nov 24, 2016
It seems like removing the shebang is enough to fix the code signing
problems discussed in the issues referenced below.

Fixes #14, Fixes #27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants