Notarisation failing with “The signature of the binary is invalid"

Question

Created 1w

Replies 1

Boosts 0

Participants 2

Error: { “logFormatVersion”: 1, “jobId”: “1654af2a-ff0e-46ff-8839-5c374e63228b”, “status”: “Invalid”, “statusSummary”: “Archive contains critical validation errors”, “statusCode”: 4000, “archiveFilename”: “LocalApp-macosx.zip”, “uploadDate”: “2024-06-12T05:33:53.719Z”, “sha256”: “28ffff0e2c33b2f57a9f1c25677e84232bfa04b1ef5341130afbbf18093ba0ab”, “ticketContents”: null, “issues”: [ { “severity”: “error”, “code”: null, “path”: “LocalApp-macosx.zip/LocalApp-macosx.app/Contents/Resources/Java/Disk1/InstData/Resource1.zip/$BUILD_ROOT$/Desktop/collaborator.app_zg_ia_sf.jar/Contents/MacOS/applet”, “message”: “The signature of the binary is invalid.”, “docUrl”: "“Resolving common notarization issues | Apple Developer Documentation ", “architecture”: “i386” }, { “severity”: “error”, “code”: null, “path”: “LocalApp-macosx.zip/LocalApp-macosx.app/Contents/Resources/Java/Disk1/InstData/Resource1.zip/$BUILD_ROOT$/Desktop/collaborator.app_zg_ia_sf.jar/Contents/MacOS/applet”, “message”: “The signature of the binary is invalid.”, “docUrl”: ““Resolving common notarization issues | Apple Developer Documentation”, “architecture”: “x86_64” } ] }

Why is the binary regarded as invalid and what remedy is recommended?

Boost

Answer 1

DTS Engineer OP

Apple

6d

Look at the path in that error:

LocalApp-macosx.zip/LocalApp-macosx.app/Contents/Resources/Java/Disk1/InstData/Resource1.zip/$BUILD_ROOT$/Desktop/collaborator.app_zg_ia_sf.jar/Contents/MacOS/applet

You submitted LocalApp-macosx.zip, so that makes sense. Within that you have Resource1.zip and within that there’s collaborator.app_zg_ia_sf.jar. The latter is a Java archive, but that’s close enough to a zip archive that the notary service will look within it. So, looking through these three levels of archives it’s found some code that’s not signed correctly.

I don’t maintain expertise in Java but my experience with other Java developers is that the Java build process often embeds native code [1] in a Java archive. That code isn’t signed properly, so when you embed the Java archive in your main app the notary service complains. There are there standard solutions:

Unpack the Java archive, sign the native code, and then repack it.
Change the build system to sign the native code before packaging it into the archive.
Relocate the native code out of the Java archive.

Beyond that, I recommend that you consult the support resources for your third-party tooling to see if they have specific advice on this topic. If not, we have general instructions in:

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

[1] By native code I mean a Mach-O image, as defined in An Apple Library Primer.

0