Unable to notarize app due to wrong libomp.dylib library signature

Hi everyone,

I am currently facing troubles to notarize the MacOS app I distribute to our customer. I successfully signed my executable and the dmg that packages it with my Apple Developer certificate.

I then successfully submitted a notarization ticket for my dmg by using "xcrun notarytool submit" command line.

Nevertheless when reading the log, my notarization fails because of the following error in the json output:

{
"severity": "error",
"code": null,
"path": "MyDMG.dmg/MyApp.app/Contents/Resources/sklearn/.dylibs/libomp.dylib",
"message": "The binary is not signed with a valid Developer ID certificate.",
"docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087721",
"architecture": "i386"
}

When running codesign -dv MyApp.app/Contents/Resources/sklearn/.dylibs/libomp.dylib I see indeed that the existing signature seems to lack some valid elements (Team ID...):

Identifier=libomp-55554944b4aef647421b3b93bf0a9f6317d56c44
Format=Mach-O universal (i386 x86_64)
CodeDirectory v=20400 size=4104 flags=0x2(adhoc) hashes=122+2 location=embedded
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=0 size=12

I tried to sign it with my Apple Developer certificate with codesign using the "-f" option to erase the existing signature but it seems like it is impossible because I get the following error:

dist/dmg/Vib3s.app/Contents/Resources/sklearn/.dylibs/libomp.dylib: library validation flag cannot be used with an i386 binary

When I check again the file the signature indeed didn't change.

I also tried using an entitlements.plist file and setting the com.apple.security.cs.disable-library-validation option to true doesn't work.

Would you guys know the proper way to proceed to successfully notarize my app please?

Replies

I'm not sure if this is the problem, but the location of the dylib in your bundle is peculiar. For one thing, the Resources folder is not one of the standard locations for nested code, according to the macOS Code Signing in Depth technote. Also, that document says

The code signing machinery interprets directories with periods in their names as code bundles and will reject them if they don't conform to the expected code bundle layout.

so that ".dylibs" folder could be a problem.

OK, let’s start with some basics. Why are you shipping 32-bit Intel code? That’s not been necessary since macOS 10.7 (2010) and it’s not been useful since macOS 10.15 (2019). How far back is your deployment target?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I had the same problem using Pyinstaller and sklearn.

I successfully notarized such an app by first codesign the .dylibs/libomp.dylib file and then the remaining using the --deep option since I believe that you did the same (which is not recommended to be used - see here: https://developer.apple.com/forums/thread/128166 and https://developer.apple.com/forums/thread/129980).

Did you resolve the issue using a different approach?

Cheers