Notarized App triggers Gatekeeper dialog

Our app is weakly linked to a framework from a third-party vendor:

/Library/KeyAccess/KeyAccess.app/Contents/SharedFrameworks/KeyAccess.framework/KeyAccess

Our app is signed using our developer ID certificate with: --options runtime --timestamp --entitlements ourApp.entitlements

Since the 3rd party framework is signed with a different developer ID, the entitlement file requests and disables library validation:

https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_disable-library-validation?language=objc

We have verified the code signature using the following commands:

codesign --verify --strict --verbose ourApp.app

codesign -dvv ourApp.app

spctl -vvv --assess --type exec --ignore-cache --no-cache ourApp.app

No issues are reported.

We generate a dmg we code sign that too, then successfully notarize the dmg and staple the report.

When viewing the log provided during notarization no issues are shown, all binary content has been properly signed.

Unfortunately, if the dmg is downloaded from an online source we get a Gatekeeper warning indicating the developer cannot be verified. If we omit the entitlement (which will result in not being able to use the 3rd party framework, but the application will otherwise run) the Gatekeeper dialog disappears.

Since this issue appeared only after we upgraded from Qt 5 to Qt 6, we created a small test app that just shows a "Hello World" message. In this case inclusion of the entitlement is not a problem until we attempt to pull in a trivially simple framework that we ship within the application bundle (QNtp.framework). We cannot find any code within this tiny library that e.g. uses a private API or anything else suspicious. If we bake the QNtp code into the test application directly instead no Gatekeeper warning is shown.

Is there some way to get a report on WHY Gatekeeper is rejecting the code signature and notarization of the sample or our full app? Unfortunately tools like Max Inspect and Taccy have not yet revealed the cause of the issue.

let myEmail = "w" + "stokes" + "@snapgene.com"

At a basic level, the answer to your question is simply "Qt". I don't use Qt at all and never have. But from what little I know, it seems to make notarization virtually impossible. I'm not entirely sure why. A couple of times I've seen people post the code they are trying to notarize, and sometimes it doesn't even look like an app at all.

I realize that isn't the answer you wanted. For some reason, people seem to ask about these Qt problems on this forum and not the Qt forums. Maybe if more people asked over there, or filed bug reports with Qt, they might become aware that this is a problem.

The solution is likely one or more of the runtime exceptions from this list. Which ones, I can't begin to guess. But the point is, these are all unusual things that most regular apps never need. Apple provides them for the oddball edge cases. But apparently, that includes all Qt-based apps.

I’ve recently been working on a cluster of posts that explain how to debug trusted execution problems. The starting point is Resolving Trusted Execution Problems. In your case I strongly suspect that you’re being hit by the issue described in Resolving Gatekeeper Problems Caused by Dangling Load Command Paths. The normal fix here is to re-enable library validation but that might not be appropriate in your case. You wrote:

Our app is weakly linked to a framework from a third-party vendor

Does your product install that? If so, my advice is that you take ownership of that code by signing it as your own. You can then re-enable library validation and life is easy.

If not, you’ll have to leave library validation disabled and then find and fix all the dangling load command paths in your product.

Share and Enjoy

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

Thanks, Quinn, it took a little time to find the needle in the haystack but your links were super helpful and you were indeed correct. For the record Qt was not at fault but due to issues with how our application was deployed and how some 3rd party libraries were being built with Conan we needed to fix a handful of references to directories outside the bundle that opened the application up to a dynamic library impersonation attacks because library validation was correctly disabled (we do not and cannot ship with our application the weakly linked library in question).

What boggles my mind is that there is no tool widely available to check for and alert to issues that can only be exposed by extensive calls to otool -l and otool -L. To rectify this, and to successfully track down the issues we had, I wrote such a script and have made it available for others to use:

https://github.com/wstokes/developmentTools/blob/main/mac/audit

Notarized App triggers Gatekeeper dialog
 
 
Q