This is just Mac being Mac. You have to re-sign any dylibs your include in your app with your own code-signing certificate. It's stupid and redundant, yes, but it's the choice Apple made.
TurboActivate dylib on MacOS X wrong signed
Hello wyDay team!
We found problem with using dynamic library of TurboActivate in our application - invalid sign of library causes Mac GateKeeper to reject application.
> codesign -dvvv libTurboActivate.dylibExecutable=/libTurboActivate.dylibIdentifier=libTurboActivate.dylibFormat=Mach-O universal (i386 ppc7400 x86_64)CodeDirectory v=20100 size=3511 flags=0x0(none) hashes=170+2 location=embeddedHash type=sha1 size=20CDHash=fcc625ea09833582d2d1bf868c953fca32f5e74dSignature size=5406Authority=wyDayAuthority=COMODO Code Signing CAAuthority=UTN-USERFirst-ObjectAuthority=AddTrust External CA RootSigned Time=20 Oct 2014 08:40:32BBCode is OFFInfo.plist=not boundTeamIdentifier=not setSealed Resources=noneInternal requirements count=1 size=188
Using command for GateKeeper:> spctl -a -vv MyApp.appMyApp.app: rejectedorigin=wyDay
After long time I found, that codesign of libTurboActivate.dylib with our certificate fixes this issue.But we are using two different certificates, and I am not sure, whether they could be mixed. Also, codesign of this library during build is not possible for us, as well - it's change SHA1 of this file.
Could you, please, ensure, that new released TA 4.0 libraries are codesign correctly for usage in signed .app package?
I am not sure, what is exactly problem, but for example, our libraries and app contains TeamIdentifier = XXXX (that corresponds with certificate from Mac), and Identifier is reversed domain (com.company.library).
PS You can send me changed dylib by email and I can test it in our application (email connected with this account)
If you just sign your App manually, it will complain whatever isn't correctly signed right? Then whatever it is complaining about, sign that first.
Just in case, here are the steps:
Do this once:
export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate"
(all on one line)
Then:
codesign --force --sign "Developer ID Application: YOUR NAME" /whatever/yourapp.app
...so if it complains here about /whatever/yourapp.app/Contents/somelibrary, sign that one first. Then try to sign the App itself again.
Check with:
spctl -a -v /whatever/file.app
This is a handy free tool that I use to dig into signing/sandboxing issues: https://itunes.apple.com/us/app/rb-app-checker-lite/id519421117