1 2 3 Previous Next 31 Replies Latest reply on Apr 23, 2017 10:03 AM by codecruncher

    Invalid symlink in Runtime bundle


      I have been codesigning my Runtime for some years now.  The Terminal codesigning worked well up to and including OS X 10.10.5.


      Under OS X 10.11.1, the codesigning is rejected ("obsolete resource envelope") and GateKeep will not open my Runtime.  I searched the internet and came across this site describing a similar error, diagnosis, and probable cause: http://furbo.org/2015/07/23/code-signing-in-el-capitan/


      When I checked my runtime, I found this:


      codesign --verbose=4 --deep --strict MyRuntime.app

      MyRuntime.app: invalid destination for symbolic link in bundle

      In subcomponent: /Users/MyUser/Desktop/MyRuntime.app/Contents/Frameworks/DBEngine.framework

      file modified: /Users/MyUser/Desktop/MyRuntime.app/Contents/Frameworks/DBEngine.framework/Versions/Current/A



      The other Frameworks in the bundle validated correctly.




        • 1. Re: Invalid symlink in Runtime bundle



          Thank you for your post.


          I have sent your post to our Development and Testing departments for review.  When I receive any feedback, I will let you know.



          FileMaker, Inc.

          • 2. Re: Invalid symlink in Runtime bundle



            Testing has forwarded your information as a Feature Request to add proper symlinks when a Runtime Solution is created.  The reason being this is a Feature Request is because the Tester was able to codesign a RunTime application with Xcode under both Mac OS X 10.11.1 and Mac OS X 10.10.4.  The Tester posted his steps:


            1. Install Xcode (Xcode 6.0.1 on 10.10.4 and Xcode 7.1 on 10.11.1, Command Line Tools is not necessary)

            2. Launch Xcode and open Preferences - Accounts tab

            3. Sign in with your Apple ID

            4. Click on View Details...

            5. Create a new Mac Development Signing Identities

              * Now you have a valid certificate in Keychain Access

              ** Customer may have other certificates but this shouldn’t matter

            6. Open Keychain Access

            7. Click on Certificates from Category

            8. Double click the Certification (Should look like “Mac Developer: YourName (XXXXXXXXXX)”)

            9. Copy the Common Name (Should look like “Mac Developer: YourName (XXXXXXXXXX)”)

            10. Launch FileMaker and create a Runtime solution

            11. Right click on the Runtime Solution and choose Show Package Contents

            12. Go to /Contents/Frameworks/

            13. Open Terminal and enter the following commands suggested by Apple Developer Technical Support

            $ cd DBEngine.framework/Versions

            $ ln -s A Current

            $ cd ..

            $ ln -s Versions/Current/DBEngine DBEngine

            $ ln -s Versions/Current/Resources Resources

            14. Repeat with all the other frameworks

            15. In Terminal, codesign the Runtime Solution with the following command:

            $ codesign --deep --force --sign “Common Name of your certificate copied in Step 9” path to the Runtime Solution.app

              * There should be no errors

              ** To verify the codesign, type the following command in Terminal

            $ codesign -vv path to the Runtime Solution.app





            FileMaker, Inc.

            • 3. Re: Invalid symlink in Runtime bundle

              Thank you, TSGal,


              I suspect the problem still exists.  Please ask the Tester to use the following  in step 15 instead of codesign -vv:


              spctl —assess -vvv path to the runtime solution.app


              This is the only way—I’m told by Apple Inc.—to verify the signature completely for the GateKeeper.


              I will try signing in Xcode to confirm tomorrow on 10.11.1 and Xcode 7.1





              • 4. Re: Invalid symlink in Runtime bundle



                In short, the steps given above don't work.  Please move this thread back to the Product Issues.


                I followed the tester's steps to the letter.  I then uploaded the signed runtime.app to the internet and downloaded back to my computer.  When I tried to open it, GateKeeper rejected it.



                Here is the verification in Terminal using both codesign -vv and spctl --assess.  See the difference?

                …$ codesign -vv onDeck.app

                onDeck.app: valid on disk

                onDeck.app: satisfies its Designated Requirement


                …$ spctl --assess -vvv onDeck.app

                onDeck.app: rejected

                origin=Mac Developer: my name (XXXXXXXXXX)


                • 5. Re: Invalid symlink in Runtime bundle



                  Thanks for the additional information.


                  The tester confirms the issue with the "spctl" command and they are reinvestigating.  I'll keep you updated.



                  FileMaker, Inc.

                  • 6. Re: Invalid symlink in Runtime bundle



                    Testing and Development are still investigating why a Runtime solution passes Codesign command but fails on spctl.  Since we announced that Runtime has been deprecated (FileMaker 14 deprecated and removed features | FileMaker), Development and Testing recommend codesigning your Runtime solution under Mac OS X 10.10.5.



                    FileMaker, Inc.

                    • 7. Re: Invalid symlink in Runtime bundle

                      Hi TSGal,


                      Before sweeping this under the deprecated rug , please consider this:


                      1. Runtimes built and codesigned under OS X 10.10.5 (Yosemite) cannot be opened normally in OS X 10.11.x.  The GateKeeper in El Capitan rejects them because "the identity of the developer can not be confirmed".  I reverified this morning with the latest updates.  (A captain once told me to never recommend a course that I haven't plotted. )


                      2.  The issue is not with codesigning nor with spctl nor GateKeeper per se.  The codesign failure is just a symptom.  The problem lies in the invalid destination for a symbolic link in the  Runtime's DBEngine framework.  This usually translates to outdated code that is accessing memory external to the application…and that is a perceived security risk.   This is why the new GateKeeper is rejecting it.   Why does the DBEngine framework in FMP Advanced validate when the DBEngine framework in Runtime does not?   (A lawyer once told me to never ask a question to which I didn't know the answer. )


                      Thanks for spending time on this issue.  I know you have better things to do.


                      Best regards,


                      • 8. Re: Invalid symlink in Runtime bundle



                        I have forwarded your comments back to Development and Testing for review.



                        FileMaker, Inc.

                        • 9. Re: Invalid symlink in Runtime bundle



                          The information received back from Apple shows that the certificate does not look like a developer ID certificate, so Gatekeeper rejects it.  Can you confirm the developer ID certificate with Apple?



                          FileMaker, Inc.

                          • 10. Re: Invalid symlink in Runtime bundle

                            Hi TSGal,


                            It is a valid developer ID certificate.  It is valid till July 11, 2017.  t is the same one I use on OS X 10.9 where it still works.  I have even created new certificates using XCode as per your instructions.  They don’t work either.  Nor did your tester’s come to think of it.



                            • 11. Re: Invalid symlink in Runtime bundle

                              Hi TSGal,


                              I received an email from CgSoftware concerning this issue:

                              I've found where the problem is

                              Each info.plist in the runtime.app content folder have this string that wasn't present in version 13





                              In version 13 it was




                              Just remove « com.apple.compilers.llvm.clang.1_0 » in all info.plist (content and all framework)


                              I will try this today to confirm.


                              Would you mind commenting on the necessity or validity of having this string in the runtime.app content?


                              Thank you,


                              • 12. Re: Invalid symlink in Runtime bundle



                                I am unable to comment.  I have sent this information back to Development for review.



                                FileMaker, Inc.

                                • 13. Re: Invalid symlink in Runtime bundle

                                  Thank you, TSGal!


                                  This afternoon, Apple released OS X 10.11.3 Beta (15D13b).  It appears to have resolved this issue.   The runtime can now be signed as is with Christian Schmitz' codesign script.  The codesigned runtime is now accepted by GateKeeper when downloaded from the net.


                                  I thank all of you who have spent time and thought on this.



                                  • 14. Re: Invalid symlink in Runtime bundle

                                    I know this is an old post, but I have a similar problem.


                                    I also have been codesigning FileMaker runtimes in version 13 for a couple of months now using Christian Schmitz' codesign script and it has been working great.


                                    Now, that I am trying to use FileMaker 14, the process completes to the end but when I run the command:


                                    spctl --assess -vvv "AppName.app"


                                    Result is:


                                    Updater.app: rejected (invalid destination for symbolic link in bundle)


                                    I've checked the paths over and over again and the syntax. Anyone have any ideas what could be causing this error?






                                    1 2 3 Previous Next