Qt Frameworks issues with MacOS notarization

p_Each

We are currently trying to have our app verified in order to distribute it outside of the app store. We are including OpenSceneGraph libraries as well as Qt frameworks in the app bundle.

This is how we did it so far:

Signed executable in Contents/MacOS folder
Signed libraries and Qt frameworks
Signed App.app folder
zipped .app and submitted for Notarization

The executable, libraries and frameworks signing is done manually with the codesign command, and to sign the whole .app we do the following:

codesign --force --verify --verbose=3 --options runtime --timestamp --entitlements App.entitlements -s "Developer ID Application: Our Dev Id" App.app

When we send the zipped .app to be notarized we usually get a quick reply informing us that the notarization was successful, but if we try to run

spctl --verbose --assess --type execute -v App.app

we get the following error:

App.app: rejected (unsealed contents present in the root directory of an embedded framework)

Also inspecting the json file with the notarization output we notice the same error, but it is marked as a warning and checking it with codesign no error is returned.

After a bit of digging we realized that the issue is related to the Qt frameworks: as a counterproof, we tried to submit the same app without the Qt frameworks and this time when the bundle was successfully notarized spctl accepted it too.
Consequently we eliminated the all symlinks in the root directory, moved the .prl files into the Resources/ folder, and created an alias to A/ in the Versions/ subfolder as suggested in several forum posts, but we have not been able to have spctl accept our bundle with the Qt frameworks. Now at the root of each framework there is just the Versions folder and nothing else (we checked with ls-lha to be sure)

What are we missing in this? Is there a way to at least get some hint on where is the unsealed content which is upsetting the verification tool?

Thank you in advance

SGaist

Can you check with the windeployqt version coming with the latest Qt 5.14 ?
Note that Qt 5.12.7 has been released, you might also want to upgrade.

SGaist

Hi and welcome to devnet,

What version of Qt are you using ?

Did you check if there was any hidden files (those starting with a dot) in the frameworks ?

p_Each

Hi, thank you for your answer. I am using Qt 5.12.2 and yes, I did check for hidden files but even when I removed them the issue persisted.

What I have saw from other tests I made in the meantime is that if I structure a framework in a way more "Apple-like" (meaning that the Versions folder contain an A folder and a Current symlink pointing to A instead of a 5) the bundle is correctly signed and validated.

Unfortunately it does not run because there are some runpaths of some framework which I have not been able to correct with install_name_tool command and are still set to QtFramework/Versions/5/QtFramework instead of QtFramework/Versions/A/QtFramework.

We have always been able to build the app with the qt frameworks but since we upgraded to Mojave 10.14.6 we need to sign (and from next month on) t notarize our app bundle to successfully distribute it outside the App Store

SGaist

Looks like there's something related on the bug report system

p_Each

Hello, thanks for the link you provided, but they did not solve our issue.
We are now trying to go down the macdeployqt path, but there must be something going on when it copies the Qt Frameworks in the Contents/Frameworks/ folder because somehow it skips (at least) one of the required frameworks.

At this point there are a few things I need to figure out: how does macdeployqt know which frameworks need to be copied inside the bundle? I have checked in the output of otool -L command and the framework is listed there. Is it anything I must check somewhere else? Is it possible to specify manually which frameworks we want to add? Is it something we need to check in our .cmake files?

Thank you again

SGaist

macdeployqt uses macOS tools to gather the required information. What was the missing framework ?

Recent version of the tool got fixed with regard to some missing framework or plugins.

p_Each

@SGaist QtOpenGL. It caused the macdeployqt command to fail during the signing process, so I tried to add it manually (using cp -R command) and to re-sign the bundle calling codesign but it gave the "unsealed contents" error again.
This is why I asked if there is a way to specify manually the frameworks to be added by macdeployqt or a way to figure out why it is not adding it

SGaist

Can you check with the windeployqt version coming with the latest Qt 5.14 ?
Note that Qt 5.12.7 has been released, you might also want to upgrade.

p_Each

@SGaist I just tried with Qt 5.14.1 and this time macdeployqt was successful. There are still some notarization issues with the hardened runtime and some default entitlements I granted to the app but at least the frameworks look in place now. Thank you for your help

sierdzio

Not sure if it will help in anything, but I used this script on a .dmg and it works well (although not reliably - Apple randomly rejects notarization calls, but it's usually to wait a bit and run it again).

p_Each

@sierdzio thanks. My notarizations issues after switching to the latest Qt version were easier to solve fortunately, I only had forgotten to enable the Hardened Runtime and to put a timestamp when signing the bundle

angadhanoa

@SGaist and @p_Each, i am facing the same problem. I have tried this in 5.12.4 and 5.14.1. The entire application gets code signed but notarization and sptcl fails because of "unsealed contents present in the root directory of an embedded framework". Spctl specifically mentions unsealed contents and when i try "codesign --verify --verbose=4 --deep" on any Qt framework. I have also tried verifying every component of the framework using the codesign command in the framework but it states that they are valid on disk and satisfies its Designated Requirement. The only file which has no code-signature in the framework is the CodeResources file created by the codesign itself and placed in the _CodeSignature folder.

I have created the following symbolic links:

QtGui.framework
|_ QtGui -> Versions/Current/QtGui
|_ Resources -> Versions/Current/Resources
   |_ Info.plist
|_ Versions
   |_ 5
      |_ QtGui
      |_ Resources
      |_ _CodeSignature
         |_ CodeResources
    |_ A -> 5 
    |_ Current -> 5

Codesign command:

"codesign --force --verify --verbose --entitlements 'abc.plist' --sign 'Developer ID Application: ABC (XYZ)' --timestamp --options=runtime --strict QtGui.framework/Versions/5 "

SGaist

@angadhanoa hi and welcome to devnet,

IIRC, there was a thread recently about the same issue which was solved. Keep searching the forum.

angadhanoa

@SGaist Thanks, I will. This is giving me a lot of headache. At first i was thinking that i have the same issue but that was not it. Once again, thank you. i will try to find that thread.

Sprezzatura

We had a similar problem. There does not appear to be any purpose for a lot of the stuff that Qt Creator piles into the ".app" file, and it interferes with Apple Notarization.

We solved the problem by simply creating a command file that deletes the conflicting files:

# Clean out detritus that prevents notarization
cd foo.app
find . -name "*.h" -delete
find . -name "*.prl" -delete
find . -name "*.cstemp" -delete
find . -name "Headers" -delete
find ./ -name "*_debug" -delete