Notarisation failing with "The signature of the binary is invalid." - but it isn't

I’m using SD 8.07 in a Mojave VM to write apps that target a suite of 32 and 64 bit Helix products.
Post Nov 2023 the scripts themselves need to be signed and notarised in the Host OS, Sonoma.
I have a Developer ID Application certificate installed in Sonoma that verifies and has an expiry date of Feb 2027.
For months now, at least up until late April 2024 I have been able to sign and notarise any app with this setup by simply selecting “Submit…”

This week though the process is failing e.g.
22:15:38.920: {
“logFormatVersion”: 1,
“jobId”: “5d618dac-854e-450e-b82c-a4b35a62cf60”,
“status”: “Invalid”,
“statusSummary”: “Archive contains critical validation errors”,
“statusCode”: 4000,
“archiveFilename”: “minminlights.zip”,
“uploadDate”: “2024-05-28T12:14:38.894Z”,
“sha256”: “727af4cd360a04e4e41d0b12c0d9e3d82413bffd5860fca9c4e8a75edd3c23ad”,
“ticketContents”: null,
“issues”: [
{
“severity”: “error”,
“code”: null,
“path”: “/minminlights.app/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”: “/minminlights/Contents/MacOS/applet”,
“message”: “The signature of the binary is invalid.”,
“docUrl”: “Resolving common notarization issues | Apple Developer Documentation”,
“architecture”: “x86_64”
}
]
}

I followed the documentation link and ran the tests recommended for the error with these results:
% codesign --verify --deep --strict --verbose=2 /minminlights
/minminlights: valid on disk
/minminlights: satisfies its Designated Requirement

From here I’m at a loss how to proceed with two issues

  1. Why is the binary regarded as invalid and what remedy is recommended?
  2. How do I get it notarised for the ARM architecture - or don’t I need to?

TIA
Lee

It’s impossible to answer that based on what you mention here. The first step is to try running spctl on the signed applet. You’ll need to grab a copy of the .zip before it gets deleted with failure.

It should just happen. Have you checked that you’re actually producing one?

After running a Submit… on the original unsigned app I captured the zip on the fly and ran spctl:
spctl --assess --verbose /minminlights.zip
/minminlights.zip: rejected
source=no usable signature

I then just Sign Only the original file and got this:
spctl --assess --verbose /minminlights.zip
/minminlights.zip: accepted
source=Developer ID

Then I Submit… the signed app and got this:
spctl --assess --verbose /minminlights.zip
/minminlights.zip: rejected
source=no usable signature

So it seems the certificate is bad in some not obvious way. I’ll regenerate the certificate and hope that fixes it. This doesn’t;t explain why it stopped working in the first place.

As to the ARM thing I only know about the Intel architectures from the failed notarisation.

Lee

By sheer luck I stumbled upon a solution: the path to the file was compromised - either too long or containing characters that SD-Notarizer couldn’t deal with, or maybe using an external drive shared with the VM is the sticking point. I tried to find out by eliminating these factors.

This path failed:
/Volumes/Shared Folders/Scripting/AS dbBackup Projects/minmin - minminlights/minminlights_2024-05-26_#46/minminlights.app

Reducing the path by moving the minminlights.app up the tree one directory at a time yielded no success - even down to the root of the Scripting volume. I think that setting the volume to ignore ownership eliminates permissions as a cause.

This path however, where the file was placed on the startup volume, succeeded, repeatedly:
/Users/quipu/Developer/minminlights.app

That would be my guess.

I am also facing the same issue, any solution for the below issue.
{
“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”
}
]
}

That path looks suspicious – there’ shouldn’t be any $BUILD_ROOT$ in there at that stage.

I am still getting the same error:

{
“logFormatVersion”: 1,
“jobId”: “a78ccda4-53d3-491f-a7aa-f13af04961d1”,
“status”: “Invalid”,
“statusSummary”: “Archive contains critical validation errors”,
“statusCode”: 4000,
“archiveFilename”: “LocalApp-macosx.zip”,
“uploadDate”: “2024-06-12T10:32:17.227Z”,
“sha256”: “727ce3a218e59776e9526079761fcf99166c261fa84ee6e04cf8159bbc4e0e28”,
“ticketContents”: null,
“issues”: [
{
“severity”: “error”,
“code”: null,
“path”: “LocalApp-macosx.zip/LocalApp-macosx.app/Contents/Resources/Java/Disk1/InstData/Resource1.zip/Desktop/collaborator.app_zg_ia_sf.jar/Contents/MacOS/applet”,
“message”: “The binary is not signed.”,
“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/Desktop/collaborator.app_zg_ia_sf.jar/Contents/MacOS/applet”,
“message”: “The signature does not include a secure timestamp.”,
“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/Desktop/collaborator.app_zg_ia_sf.jar/Contents/MacOS/applet”,
“message”: “The executable does not have the hardened runtime enabled.”,
“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/Desktop/collaborator.app_zg_ia_sf.jar/Contents/MacOS/applet”,
“message”: “The binary is not signed.”,
“docUrl”: “Resolving common notarization issues | Apple Developer Documentation”,
“architecture”: “x86_64”
},
{
“severity”: “error”,
“code”: null,
“path”: “LocalApp-macosx.zip/LocalApp-macosx.app/Contents/Resources/Java/Disk1/InstData/Resource1.zip/Desktop/collaborator.app_zg_ia_sf.jar/Contents/MacOS/applet”,
“message”: “The signature does not include a secure timestamp.”,
“docUrl”: “Resolving common notarization issues | Apple Developer Documentation”,
“architecture”: “x86_64”
},
{
“severity”: “error”,
“code”: null,
“path”: “LocalApp-macosx.zip/LocalApp-macosx.app/Contents/Resources/Java/Disk1/InstData/Resource1.zip/Desktop/collaborator.app_zg_ia_sf.jar/Contents/MacOS/applet”,
“message”: “The executable does not have the hardened runtime enabled.”,
“docUrl”: “Resolving common notarization issues | Apple Developer Documentation”,
“architecture”: “x86_64”
}
]
}

Issue in the applet file. so I did the below action:

  1. Extracted the applet file.
  2. Sign in both applet~.x64 and applet~.x86 files.
  3. Zipped the x64 and x86 file to applet.zip and renamed the file to applet without .zip extension
  4. Added dummy text file(readme.txt) to the uninstall.zip folder
  5. Sign the LocalApp-macosx.zip succeeded without any error.
  6. Notarization the Localapp-macosx.zip succeeded without any error
  7. Installation is done in mac.
  8. When we open the local application getting the below error:
    You can’t open the application “collaborator.app” because it may be damaged or incomplete.

Why is the “applet” binary regarded as invalid?

They’re telling you it’s not signed properly. have you accepted the latest developer agreement?

I don’t think that’s the way to go.

Yes, I know the above action is not the proper way. How to fix this issue.

Have you checked your developer account for any outstanding agreements?

No oustanding agreements.

Try a Sign Only… and then run spctl on it, to see if that tells you more.

saskrish@saskrish-mac ~ % spctl --assess --verbose /Users/saskrish/Downloads/LocalApp-macosx.app/Users/saskrish/Downloads/LocalApp-macosx.app: acceptedsource=Developer ID

How did you sign it?