QtWebView, QtBluetooth, etc., are not being codesigned correctly

Question

Created Apr ’22

Replies 1

Boosts 0

Participants 2

I've only started to learn about the notarization process within the past eight months. About every three weeks or so, after I've added features to a piece of software I'm writing, I check to make sure I can still get it notarized. Everything worked fine until today.

My workflow is the following (I'm running Mac 11.6.1)

My program is written in python using tkinter and converted to an .app using pyinstaller. It runs fine on my own machine. I'm not using XCode.
Build the package:

productbuild --component Desktop/dist/my_app.app Desktop/my_app.pkg

Product sign the package:

productsign --force --deep --sign 'Developer ID Installer: MyName (XXXXXX7RBW)' /Users/Desktop/my_app.pkg /UsersDesktop/my_app_signed.pkg

Check that code is signed.

pkgutil --check-signature Desktop/my_app_signed.pkg

Obtain an app specific password by visiting https://appleid.apple.com/account/manage
Submit for notarization:

xcrun altool --notarize-app -f Desktop/my_app_signed.pkg --primary-bundle-id XXXXXX7RBW -u my_email_address -p' @keychain: Developer ID Installer: MyName (XXXXXX7RBW)

Enter my app specific password when instructed to do so.

When things worked fine a few weeks ago, there was an extra step before completing step (2): For some reason I had problems signing and notarizing up to that time due to directory names containing periods. These were located in PyQt5 within the application bundle. I deleted these folders, notarization worked, and my program ran fine on a different Mac.

Now the notarization fails due to several executables inside Contents/MacOS/ , such as QtDesigner, QtMacExtras, QtNetwork, and a few others starting with Qt. One exception consists of the dylib file libz.1.2.11.dylib. The log yields the typical "lack of a valid time-stamp" or "lack of valid developer IT certificate" messages.

The only real difference in my package since I had it last notarized three weeks ago is that it now utilizes a python module, netgraph, which is likely using aspects of PyQt.

So, I'm seeking advice for how to address this error.

Am I correct that I will need to sign the problem executables individually? If so, what is the correct way to do so. For example, instead of creating my package and product signing, should I code sign the individual problem executables and then package them with the app?

Thanks

Boost

Answer 1

DTS Engineer OP

Apple

Apr ’22

productsign --force --deep …

productsign has no --deep option:

% productsign --deep --sign "Developer ID Installer" MyApp.pkg MyApp-signed.pkg
productsign: unrecognized option `--deep'
…

I think you’re mixing up productsign and codesign. Two things to note on that front:

In most cases you don’t need productsign. You can sign your installer package while building it using the --sign argument to productbuild.
The fact that you mention --deep suggests that you’re passing that flag to codesign. I recommend against that, for the reasons explained in --deep Considered Harmful.

2. Submit for notarization:

FYI, altool has been deprecated for the purposes of notarisation. Switch to notarytool; it’s better, stronger, and faster. For the details, see WWDC 2021 Session 10261 Faster and simpler notarization for Mac apps.

For some reason I had problems signing and notarizing up to that time due to directory names containing periods.

This is a known gotcha, documented in Technote 2206 macOS Code Signing In Depth. It typically only affects folks who aren’t following the nested code rules documented in Placing Content in a Bundle and then try to sign to sign with --deep.

Am I correct that I will need to sign the problem executables individually?

Not just the problematic ones. I recommend that you sign all your code items separately, from the inside out. For detailed advice on that front, see:

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

0