0

I have an app bundle containing a cli tool and a dylib. For testing I am calling the cli tool in Terminal (iTerm2):

DYLD_INSERT_LIBRARIES=./libwebsockets.14.dylib THNUCLNT_SVC="private" ./thnuclnt -v

dyld: Library not loaded: @rpath/libwebsockets.14.dylib Referenced from: /Users/rwelz/Downloads/ezeep Connector.app/Contents/Resources/thnuclnt/thnuclnt/x86_64-darwin/./thnuclnt Reason: image not found Abort trap: 6

When I remove the signature from cli tool, everything works fine:

codesign --remove-signature thnuclnt

DYLD_INSERT_LIBRARIES=./libwebsockets.14.dylib THNUCLNT_SVC="private" ./thnuclnt -v

ThinPrint Client Mac Version 7.6.10.1, (c) 2007-2019 ThinPrint GmbH

removing signature from libwebsockets.14.dylib has no effect at all.

I know that the cli tool is using dlopen to load the dylib. But I have no code for the cli tool nor for the libwebsockets.dylib since these are programmed by a colleague of mine. I am only responsible for putting everything together in the app bundle. But everything is build on our build server - so everything uses the same certificate for code signing.

I expect my cli tool to load libwebsockets.dylib and execute and output the same as if it had no signature.

What is changing on the cli tool when codesign is applied? What is going on here?

Many thanks for your valuable help

regards,

Robert

PS.:

libwebsockets.14.dylib and tnuclnt reside in the same directory inside the resource folder of the app:

~/Downloads/my_supersecret.app/Contents/Resources/thnuclnt/thnuclnt/x86_64-darwin/] $ ls -l

total 3368

-rwxr-xr-x 1 rwelz staff 268K Sep 25 11:35 libwebsockets.14.dylib

-rwxr-xr-x 1 rwelz staff 321K Sep 25 11:35 thnuclnt

Robert
  • 160
  • 9
  • 1
    What was `rpath` set to when `thnuclnt` was built? – trojanfoe Sep 25 '19 at 11:07
  • How do I get this information? thnuclnt is no Xcode project (no Xcode-build call) otool -L thnuclnt says: ... @rpath/libwebsockets.14.dylib (compatibility version 14.0.0, current version 0.0.0) ... – Robert Sep 25 '19 at 11:21
  • Before signing we applied install_name_tool -change @rpath/libwebsockets.14.dylib @executable_path/libwebsockets.14.dylib thnuclnt and the error is gone. Now we get a new one: dyld: Library not loaded: /usr/local/ssl/lib/libssl.0.9.8.dylib Referenced from: /Users/bsvc/Codeshare/test/x86_64-darwin/./thnuclnt Reason: image not found Abort trap: 6 What is the install_name_tool call to bend /usr/local/ssl/lib/libssl.0.9.8.dylib to /usr/lib/libssl.0.9.8.dylib ? – Robert Sep 25 '19 at 11:43
  • 1
    The `rpath` is set during linking and is normally something like `../Frameworks` when building a macOS app bundle. It's a way of setting the location of all the `dylib`s in a more abstract way. The other error you talk about means libssl is a third-party library which will also need bundling as users wont have it installed in their system. You will have to do a similar job with `install_name_tool` on that too. – trojanfoe Sep 25 '19 at 11:51
  • install_name_tool -change /usr/local/ssl/lib/libssl.0.9.8.dylib /usr/lib/libssl.0.9.8.dylib thnuclnt install_name_tool -change /usr/local/ssl/lib/libcrypto.0.9.8.dylib /usr/lib/libcrypto.0.9.8.dylib thnuclnt did the trick. Thanks for your input. Regards, Robert – Robert Sep 27 '19 at 13:03
  • Does someone know, why changing the @rpath is neccessary for signed cli tool and dylibs and not for unsigned ones? Whats the difference in Gatekeeper's behaviour between signed and unsigned binaries? – Robert Sep 27 '19 at 13:06
  • Hmm, that looks way off. If those libraries are from `/usr/local` they need to copied into the app bundle as they won't exist on the end-user system. If they are standard and live in `/usr/lib` then why are you linking in from `/usr/local/`? – trojanfoe Sep 27 '19 at 13:06
  • That tool is build not under my control (on a build server). I am not able to change anything there. – Robert Sep 27 '19 at 13:08

0 Answers0