11

I'am trying to code sign an app bundle on osx mavericks 10.9.5 with format v2. On previous testing the signing on 10.9.5 (13F12) all went well, all frameworks could be signed without error. Now, on 13F34, the frameworks could not be signed any more. When i try to sign the first framework with: 

codesign -f -v -s "Developer ID Application: MY AG" "My.app/Contents/Frameworks/4DJavaScript.framework"

then the error occurs: 

My.app/Contents/Frameworks/4DJavaScript.framework: bundle format is ambiguous (could be app or framework)

When I try to code sign the only version (A) of the framework, the signing succeeds, but on signing the main app the error on the framework reappears. On looking into the info.plist file of the framework there is (in my sense) the correct entry for the type set: 

Bundle OS Type code FMWK

Any suggestions on how to code sign a framework correctly on 10.9.5-13F34?
Thanks, Peter

Andrew Madsen
  • 21,309
  • 5
  • 56
  • 97
Peter
  • 111
  • 1
  • 4

4 Answers4

13

Your answer didn't work for me so I post mine.

If you previously copied frameworks with cp -r command you will have this problem. With cp -a this problem doesn't appear. That's happening because of different way of resolving symlinks in these two options.

htzfun
  • 1,231
  • 10
  • 41
  • 7
    This is the correct answer! codesign break, when symlinks get resolved into directories. In a framework, toplevel folders must be symlinks pointing to Versions/Current and Current must be a symlink to the actual version. Usually 'A'. Signing 'Versions/Current' might be a workaround, if you cannot fix the structure. Apple, please fix your codesigner, to say something about bad symlink structure, instead of 'bundle format is ambiguous'. – Jürgen Weigert Oct 05 '18 at 13:28
  • I owe a big thanks to @JürgenWeigert - I was trying to codesign my app for Catalina and kept getting this error (bundle format). I saw in [codesign docs](https://developer.apple.com/library/archive/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG313) one reason is a problem with symlinks. I looked inside my app and found the symlink structure wasn't correct, so I manually adjusted it and it worked. Here's [a post that suggests the structure, look for the comments by Dass](https://stackoverflow.com/questions/27871099/creating-symlinks-in-osx-frameworks-inside-app-bundle) – user150812 Sep 26 '19 at 02:29
  • Thanks bro @JürgenWeigert you saved my day! – merlin.ye Sep 10 '20 at 12:06
10

Immediately after posting the bounty on this question, I figured it out. Signing the current version of the framework directly does the trick:

codesign -f -v -s "Developer ID Application: My Dev ID" MyFramework.framework/Versions/Current
Andrew Madsen
  • 21,309
  • 5
  • 56
  • 97
  • im facing this issue. I am not getting your solution. please can you tell in detail – Qadir Hussain May 08 '15 at 08:52
  • 1
    @QadirHussain I'm not sure what more detail there is to add. I simply used the codesign tool to directly sign the current version of the framework's executable very much like the example in my answer. – Andrew Madsen May 08 '15 at 14:38
  • Also you have to ensure that your app does not make use of --deep code signing flag – Alberto García Mar 08 '22 at 19:31
2

I was using electron-packager and needed to use the --no-deref-symlinks flag and bam working for me

KleggerKoder
  • 161
  • 1
  • 10
1

I ran into the same problem. In my case the problem was that the .app file I was trying to codesign was stroed in a dropbox folder.

Apparently, dropbox resolves symbolic links by default, i.e. symlinks are completely replaced by the data they point to. Read about it here.

The codesign command cannot recognize the format of the bundle after dropbox resolves the symlinks.

The solution is to not store the bundle you are trying to codesign in a dropbox folder.

J.beenie
  • 861
  • 10
  • 22