0

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

p_Each
  • 11
  • 3
  • I think that probably there are other issues than QtFrameworks, i have successfully notarized a Qt-based application that uses QtNetwork, QtMultimedia, sql plugin and a few other modules. Have you checked the paths of the linked libraries? Have you deployed your app with macdeployqt? – Alienpenguin Jan 30 '20 at 08:15
  • @Alienpenguin No, we are not using macdeployqt. Are you? How did you set the QtFrameworks Versions folder and the runpaths? Because from a test I made yesterday it seems like that structure is the issue. When I changed manually the Versions/ folder (renamed the 5/ folder to A/ and have Current/ symlink it) the notarization was successful without errors or warning. Unfortunately then it was not possible to run the app because we did not manage to change all the runpaths and they still referenced Versions/5/. Even calling `install_name_tool` directly on them did not have any effect – p_Each Jan 30 '20 at 14:50
  • 1
    @p-each If it is a Qt-based application you should use macdeployqt that will create the bundle, arrange the QtFrameworks and use the install_name_tool accordingly. have a look at https://doc-snapshots.qt.io/qt5-5.9/osx-deployment.html – Alienpenguin Jan 30 '20 at 16:14
  • @Alienpenguin thanks. I tried that too but it seems to be doing something strange somehow it does not add all the QtFrameworks I need (eg it misses QtOpenGL). I need a way to figure out why it is missing it and before you waste your time suggesting me to check my .pro file I have to tell you that this project has been created with CMake and from there it seems ok. Also because it has ben successfully built and distributed in the past before all this signing and notarization stuff became a thing – p_Each Jan 31 '20 at 09:45
  • Anyways, @ which qt version? – Richard Barber Feb 03 '20 at 09:19
  • Also, you are wiping out the inner signatures when you sign the app. I always use ` --deep --preserve-metadata=identifier,entitlements,runtime --timestamp --strict -v ` – Richard Barber Feb 03 '20 at 09:25

1 Answers1

1

In the end, turns out macdeployqt was the way to go, because it automatically arranges the Frameworks in a way that makes it possible to sign the bundle with no error.

Our problem with some framework not being added by macdeployqt disappeared when we upgraded from Qt 5.12.2 to Qt 5.14.1

p_Each
  • 11
  • 3