Codesign of Dropbox API fails in Xcode 4.6.3: “code object is not signed at all”

I think I may have figured this one out. I’ve been running Xcode 4.6.3 on OS X Mavericks, under the impression that any build-specific tools were bundled in the Xcode application.

But, it seems codesign is in /usr/bin. Whether it’s put there by one of the Xcode installers or comes with a vanilla system install, I’m not sure. But reading through the man page for codesign, I found this nifty option:

--deep  When signing a bundle, specifies that nested code content such as helpers, frameworks, and plug-ins, should be recursively signed
             in turn. Beware that all signing options you specify will apply, in turn, to such nested content.
             When verifying a bundle, specifies that any nested code content will be recursively verified as to its full content. By default,
             verification of nested content is limited to a shallow investigation that may not detect changes to the nested code.
             When displaying a signature, specifies that a list of directly nested code should be written to the display output. This lists only
             code directly nested within the subject; anything nested indirectly will require recursive application of the codesign command.

And then I found this post (https://alpha.app.net/isaiah/post/6774960) from two weeks ago (~June 2013), which mentions (albeit second-handedly):

@isaiah I asked a guy in the labs about it. He said codesign now
requires embedded frameworks to be signed separately before code
signing the app bundle as a whole.

Manually re-running the codesign command that Xcode normally runs, while adding the --deep flag to the end, signs the application properly.

I’m not yet sure exactly what ramifications this manual signing has, or whether I can tweak the Xcode build to add the --deep flag automatically, but this seems to be the underlying issue. (codesign no longer automatically deeply signs your app bundle.)

Leave a Comment