I've been given an Xcode project which produces a command line tool which links to a dylib. I have the dylib, but not its source code.
I change the signing option for the command line tool target so it is signed automatically by my personal team.
On an attempt to run the tool, it fails to load the dylib, because the dylib is signed with a different certificate. I manually codesign the dylib with the same certificate I am using for the command line app.
Now, I can build the app, but not run it. If I try to do so, I see four dialogs telling me “libXXX.dylib” can’t be opened because Apple cannot check it for malicious software, then the console tells me "'/path/to/libXXX.dylib' not valid for use in process: library load disallowed by system policy)"
I found an old document about Gatekeeper (https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html) which suggests that Gatekeeper just won't let me do this - I can't just put the dylib next to the executable, although the dynamic linker finds the dylib, Gatekeeper doesn't like it because the dylib isn't inside the app bundle (there is none), and isn't in one of the well-known places.
I dealt with this by making a do-nothing app which I can sign with my personal certificate. Then I replace the signature on the dylib (and its dependent dylibs) with my own. I add the command line tool and all its dylib dependencies to the do-nothing app, then add those files into the Copy Bundle Resources phase of the do-nothing app.
Now, the command line tool and its dylibs all live in do-nothing.app/Contents/Resources, and I can run the tool from there without Gatekeeper complaining.
Is there an easier way (aside from asking my supplier for static libraries)? And if this is the only way, is Contents/Resources the right place to put command line tools and the dylibs they link to?