Signing and Notarisation of dmg losing signature info of bundled libraries

Question

Created Sep ’22

Replies 3

Boosts 0

Views 1.6k

Participants 2

I have used some third party tools to create an app for MacOS platform and followed the "Manual Code Signing Example" in the Developer Forums to sign and notarize my app bundle.

Other than the app bundle and the main executive, all files are libraries. So I remove their signatures and sign them according to their dependance with specific bundle IDs.

codesign -s $developer_ID -f --timestamp -i $this_bundle_ID $file

Then sign the app bundle:

codesign -s $developer_ID -f --timestamp -o runtime --entitlements "${WORKDIR}/app.entitlements" "${APP}"

I have check through all the files are signed with Authority=Developer ID Application: Developer ID Certification Authority

and timestamp Timestamp=dd MMM YYY at hh:mm:ss

I pack the app into dmg by using hdiutil and sign it using my Developer_ID: Application. the codesign -dvv still report OK for the dmg.

However, once I upload the dmg for notarisation and do a check:

% xcrun notarytool history --keychain-profile "my_keychain"

it report as:

Successfully received submission history.
  history
    --------------------------------------------------
    createdDate: 2022-09-14T08:16:16.707Z
    id: My_submission_ID
    name: MyApp.dmg
    status: Accepted
    --------------------------------------------------
    createdDate: 2022-09-04T03:05:35.977Z
    id: My_submission_ID
    name: MyApp.dmg
    status: Invalid`

Looking into the issue, I do a xcrun notarytool log My_submission_ID --keychain-profile "my_keychain"> error_log.txt

It reports all my files except for the app executable don't have certificate and timestamp.

"issues": [
    {
      "severity": "error",
      "code": null,
      "path": "MyApp.dmg/MyApp.app/Contents/MacOS/Python",
      "message": "The binary is not signed with a valid Developer ID certificate.",
      "docUrl": null,
      "architecture": "x86_64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "MyApp.dmg/MyApp.app/Contents/MacOS/Python",
      "message": "The signature does not include a secure timestamp.",
      "docUrl": null,
      "architecture": "x86_64"
    },

I would very much appreciate it if someone could show me some pointers.

Thank you in advance.

Boost

Answer 1

DTS Engineer OP

Apple

Sep ’22

Is Python listed as the main executable for your bundle in its Info.plist?

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

0

Answer 2

chanbangyuan OP

Sep ’22

No, My Info.plist's "CFBundleExecutable" is MyApp, that is the only main executable in the bundle. When I do a file command on the Python file, it shows:

MyApp.app/Contents/MacOS/Python: Mach-O 64-bit dynamically linked shared library x86_64

I just listed one file as example, there are a total of 151 dylib or so files. I have signed all of them but the report are the same as above.

BTW, after I submitted this post, I found out the re-signed MyApp.app has broken even before packing into dmg. That may lead to the notarization engine abort checking and report as such.

Although the pyinstaller has parameters in the .spec file that would sign the app automatically for me. I didn't use that and wish I could re-sign the codes by myself. So by default all the codes are signed with adhoc signature. I have no idea that just by signing it would break the code.

My options left:

Let pyinstaller sign my code
Use pyoxidizer to package and they have a signing tool. Hopefully they can support pyQt6 properly.
Use py2app to package

Unfortunately, they are all third party tools. But thanks anyway for your answer, Quinn “The Eskimo!”

0

Answer 3

DTS Engineer OP

Apple

Sep ’22

Unfortunately, they are all third party tools.

If you engage with these vendors and find them interested in improving their Apple platform support, I’m more than happy to help them understand what the issues are and suggest paths forward that are likely to be compatible in the long term. Such conversations are best held in the context of a DTS tech support incident, but if they don’t have any TSI assets you can open one yourself and then invite them into that conversation.

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

0