Notarization and weak linking to 3rd-party frameworks

Hi there,

My app detects connected BlackMagic devices on a user's machine and this is done using the DeckLink SDK which first tries to load /Library/Frameworks/DeckLinkAPI.framework using CFBundleCreate. I have not been able to create a notarized app which successfully detects the devices. Either the DeckLinkAPI works or the app starts up without showing "the developer cannot be verified" on my test computer but never both.

This is what I've tried so far:

  • signed app: DeckLinkAPI available
  • hardened runtime: DeckLinkAPI not available
  • hardened runtime + com.apple.security.cs.disable-library-validation: DeckLinkAPI available, notarization succeeds yet the "the developer cannot be verified"

I've also tried to use weak linking to DeckLinkAPI.framework instead of including the SDK's CFBundleCreate code but that made no difference: I still needed the com.apple.security.cs.disable-library-validation entitlement for that to work which caused "the developer cannot be verified".

DeckLinkAPI.framework is notarized:

> codesign --test-requirement="=notarized" --verify --verbose /Library/Frameworks/DeckLinkAPI.framework

/Library/Frameworks/DeckLinkAPI.framework: valid on disk
/Library/Frameworks/DeckLinkAPI.framework: satisfies its Designated Requirement
/Library/Frameworks/DeckLinkAPI.framework: explicit requirement satisfied

Is there any way to successfully notarize an app to use the DeckLink SDK or any other thirdparty notarized framework which is distributed seperately?

Answered by DTS Engineer in 789959022

You’re almost certainly suffering from the problems described in Resolving Gatekeeper Problems Caused by Dangling Load Command Paths. You need to disable library validation because you’re loading code signed by another third-party developer. Given that, you have tidy up any dangling load command paths.

Share and Enjoy

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

Accepted Answer

You’re almost certainly suffering from the problems described in Resolving Gatekeeper Problems Caused by Dangling Load Command Paths. You need to disable library validation because you’re loading code signed by another third-party developer. Given that, you have tidy up any dangling load command paths.

Share and Enjoy

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

Thanks Quinn, that's exactly what it was. The rpath that snuck in there came from a CMake target_link_directories command and after changing it to an equivalent find_library command, the load command path was gone from the executable and the App worked perfectly.

Notarization and weak linking to 3rd-party frameworks
 
 
Q