We have a multi-platform suite of command-line executables and libraries that we ported to Mac; I'm new to Mac development. The file layout was
/Applications/
- (company folder)/
- (our UI).app
- (product name)/
- bin/
- ...executalbes...
- lib/
- ...dylibs...
- (other stuff)/...
- bin/
This was shipped in a DMG that was codesigned, as was the app. This worked OK until Catalina.
Now on Catalina, we have codesigned all the executables, dylibs, apps (including ones nested in the top-level app's framework), frameworks, and the DMG itself. When we notarize it the resulting JSON log lists no issues. However, when I run any of our executables that depends on one of our dylibs I get a pop-up telling me the "developer cannot be identified". Even though it has been signed and notarized OK. Running codesign with -dvvv option includes the following:
- SHA-256 hash choice
- list of Authority entries terminating in Apple Root CA
- TeamIdentifier entry
- Timestamp
- Runtime: 10.13.0
Question How can I fix this, or at least get Gatekeeper to tell me why it's not accepting this file? Maybe a log, or an equivalent of spctl --assess for files rather than apps?
Observations
- This only happens when
- the OS is Catalina
- it's under the /Applications folder
- outside of /Applications (e.g. in a folder on desktop) it only happens sometimes (and sometimes it claims a dylib can't be loaded on first attempt, then succeeds if tried a moment later)
- the executable depends on one or more of our dylibs (standalone ones run OK)
- the executable has the com.apple.quarantine xattr set
- I've tried to mix'n'match between clean and downloaded (i.e. quarantine-xattr'd files) and the problem only arises if the executable is quarantined; it doesn't care if a non-quarantined executable loads a quaratined dylib
- The signing operation was done via codesign with args "--deep --strict --timestamp --options runtime", and then verified
- I've since updated this to include some of the Hardened Runtime entitlements to fix another build issue, but it hasn't helped with this one
- The executables depend on the dylibs via @rpath (as reported by otool -L)
- Result of "spctl --assess -t open --context context:primary-signature -v" on the DMG
- accepted
- source=Notarized Developer ID
- Result of "spctl --assess --context context:primary-signature -v" on the app
- accepted
- source=Notarized Developer ID
- Result of running it on the various nested apps in the app's Contents/Framework/nwjs Framework.framework/Helpers/ folder
- rejected (the code is valid but does not seem to be an app)
- (I'm not sure this is relevant to the problem at hand, but I just ran into it.)
- This only happens when
