Add ability to view code signing entitlements in the application binary

[tonyxiao]

This will help debugging issues such as the following.

http://www.karlmonaghan.com/2012/08/09/invalid-ipa-the-keychain-access-group-in-the-embedded-mobileprovision-and-your-binary-dont-match/

[tonyxiao]

Viewing application binary with a hex editor and search for text keyword like "keychain" will reveal the presence of such entitlements

[ealeksandrov]

Interesting, thanks, I'll check it out.

[ealeksandrov]

What entitlement info you would like to see? There is something already:

[ealeksandrov]

Closing, as it already displays all bundled entitlements.

[tonyxiao]

@ealeksandrov I'm talking about the entitlements that you would see from running codesign -d --entitlements - YourApp.app on your app, which can be different from embedded.entitlements if app was incorrectly signed.

[tonyxiao]

My workflow currently involves unzipping the IPA and then run the above command to display entitlements info encoded into application binary, and then compare that with entitlement info in the provisioning profile (which is what provisionQL displays). It would be super nice if these things were right there alongside each other.

[ealeksandrov]

Thanks for mentioning it!

[mgrebenets]

+1 for this one.
The entitlements that plugin displays right now come from embedded.mobileprovision, but the actual entitlements are usually different. We use similar command: codesign -d --entitlements - path/to/App.app.

For us it's super important, because provisioning profile will always have keychain-access-groups @entry like this:

    <key>keychain-access-groups</key>
    <array>
        <string>FPBCDAABCD.*</string>
    </array>

But the actual entitlements are like this:

        <key>keychain-access-groups</key>
    <array>
        <string>FPBCDAABCD.au.com.company.app</string>
        <string>FPBCDAABCD.au.com.company.shared</string>
    </array>

So it would be very useful if we could look at those with the plugin instead of running shell commands each time.

[thdankert]

See PR #16