Invalid signature when trying to notarize dmg

Question

Created Feb ’22

Replies 1

Boosts 0

Views 1.2k

Participants 2

I have an .app file (built with Unity), notarizing it fails, showing this error in the log:

"path": "myapp.dmg.zip/12/myapp.dmg/myapp.app/Contents/MacOS/myapp.dev",
"message": "The signature of the binary is invalid.",

Although when running codesign -vvv --deep --strict I get .app: satisfies its Designated Requirement

The code I use first signs the .app, creates a .dmg and sign it too:

codesign --deep --force --verify --verbose --timestamp --options runtime --entitlements "$entPath" --sign "$cert" "$appPath"
appdmg ./mac/appdmg.json $dmgPath
codesign --deep --force --verify --verbose --timestamp --options runtime --entitlements "$entPath" --sign "$cert" "$dmgPath"
ditto -c -k --sequesterRsrc --keepParent "$dmgPath" "$zipFileName"
altool --notarize-app --primary-bundle-id "$bundleID" --username "$username" --password "@keychain:signappkey4" --file "$zipFileName"

The certificate I use for both is the 'Developer ID Application'. What am I doing wrong or how can I pinpoint the problem?

Boost

Answer 1

DTS Engineer OP

Apple

Mar ’22

OK, there’s a bunch of things to deal with here, and it’s not clear which one is the cause of your specific problem.

First up, 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.

Second, don’t use --deep when signing. See --deep Considered Harmful. And for detailed instructions on how to sign a product manually, see Signing a Mac Product For Distribution.

Third, this is a concern:

ditto -c -k --sequesterRsrc --keepParent "$dmgPath" "$zipFileName"

It’s best to avoid relying on extended attributes in a Mac app (because there are various distribution channels that strip them). And if you do have extended attributes, --sequesterRsrc is unlikely to be your friend; that only makes sense if your transferring the zip archive to someone who wants to discard the extended attributes. For more on this, see Extended Attributes and Zip Archive.

Having said that, it looks liike you’re doing this when creating your disk image. That’s unnecessary on two fronts:

Disk images don’t use extended attributes [1].
You don’t need to zip your disk image; upload it directly to the notary service.

Forth, the hardened runtime (--options runtime) and entitlements (--entitlements "$entPath") make no sense on a disk image. Don’t set them.

Finally, this is nonsense:

codesign … --verify … --sign "$cert" "$appPath"

It’s telling codesign to both sign and verify. I’ve no idea what that’ll do [2]. Honestly, I’m surprised it doesn’t error out, because the codesign man page says:

codesign requires exactly one operation option to determine what action is to be performed

If none of the above helps, grab the disk image you submitted for notarisation, mount it, run the following command against the app on the image, and then post the results:

% codesign --verify --deep --strict /Volumes/MyDiskName/MyApp.app

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

[1] I’m talking .dmg files specifically. Very old traditional Mac OS disk images did use resources.

[2] Some testing (on macOS 12.2.1) suggest that the last operation is the one that holds sway but, yeah, don’t rely on that.

0