Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Store submission fails with iCloud entitlements #798
When a provisioning profile has iCloud entitlements enabled, the buck signed binary will not pass store submission. A typical iCloud provisioning profile will have entitlements similar to:
The default entitlements handling in buck will combine the specified entitlements file with the entitlements in the provisioning profile. This will result in both the
I'm not sure where the behaviour of merging the entitlements came from, is this mirroring what Xcode would do? It seems more correct to not merge the entitlements, would this result in a different error though, do we always need to merge certain keys from the provisioning profile?
I've done a bit of digging on this, it does appear that Xcode uses a similar approach with a blacklist of keys not to merge into the entitlements file. The list seems to include:
The behaviour is complex enough that it seems pretty risky trying to replicate it inside buck itself. Perhaps a wrapper around the system entitlements merging code is the best approach here?
Yes, this is unfortunate. I have tracked down the class that does most of the heavy lifting, it is in an Xcode framework: https://github.com/luisobo/Xcode-RuntimeHeaders/blob/master/IDEFoundation/IDEArchivePackagerEntitlementsMerger.h
So the options we have are:
I was leaning towards the first approach and using JNI to invoke the framework, but this seems to be impossible due to the way that the rpath has been setup for the framework, it would require manually loading every single dependent framework as it seems runpath search flags are not correctly passed down to the JNI framework. Wrapping this in a C tool is still an option, and probably the safest course if a bit fiddly.
Otherwise we just work out what it is doing and replicate the logic, but it is unfortunately doing quite a lot more than you would expect, including adding in defaults, replacing wildcards, blacklisting a whole bunch of keys (which presumably change with every tooling upgrade) and doing some verification of some of the keys.
I think in the short term we should take the second approach and look to make this more solid down the line, thoughts?
I agree the second approach is better as (platform considerations aside) depending on a private interface is something I'd like only as a last resort.
Either way, we're susceptible to Apple's changes. The second approach where we do our own implementation is advantageous in that any future breakage is more visible and presumably easier to fix.
As a side note In the longer term, we're moving away from hard-coding things like this in Java and moving more towards Python for the execution of the build steps themselves.
referenced this issue
Jul 7, 2016
OK, I added a blacklist to filter out invalid keys for now. There is also some validation behaviour that I left out, but from what I can tell this is to do with