Notarization failing "The signature of the binary is invalid."

I have been successfully notarizing my app until a few days ago, when I started getting the error "The signature of the binary is invalid."

Is that message coming from the notary service? If so, presumably that’s from an item in the issues array of the notary log. If so, please post the full item, not just the message.

You can fetch the notary log using the log command of notarytool [1].

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

[1] Assuming you’re using notarytool, which you should be. The previous option, altool, is now deprecated for the purposes of notarisation. See WWDC 2021 Session 10261 Faster and simpler notarization for Mac apps.

If you’re still using altool for notarisation, consider switching. If you can’t switch now, plan some time for that in the future.

To get the notary look using altool, run the --notarization-info command, look for the returned LogFileURL property, and fetch that.

Yes, you are correct, I am using altool. I will switch to notarytool. I have been getting the --notarization-info, but it's not very enlightening:

{
  "logFormatVersion": 1,
  "jobId": "8863eb65-048a-4cf8-b713-02520a396a11",
  "status": "Invalid",
  "statusSummary": "Archive contains critical validation errors",
  "statusCode": 4000,
  "archiveFilename": "MyPackage.pkg",
  "uploadDate": "2022-02-06T22:42:56Z",
  "sha256": "95f1dc7b8a7f83ac954bc4a41909d339f552c56db3c53ac43270e15bf347e135",
  "ticketContents": null,
  "issues": [
    {
      "severity": "error",
      "code": null,
      "path": "MyPackage.pkg Contents/Payload/Applications/MyApp.app/Contents/MacOS/name-of-executable",
      "message": "The signature of the binary is invalid.",
      "docUrl": null,
      "architecture": "x86_64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "MyPackage.pkg/Contents/Payload/Applications/MyApp.app/Contents/Helpers/a-dll.app/Contents/MacOS/a-dll",
      "message": "The signature of the binary is invalid.",
      "docUrl": null,
      "architecture": "x86_64"
    }
  ]
}

I'm using macOS 10.15 (Catalina), so I can develop and reach back to as many users as possible.

I am using XCode 12.1. Apparently notarytool is not compatible with XCode 12.1, and I have to continue using altool?

So, I still have a problem. I have displayed the log returned from LogFileURL (see above), but there is no useful information. Why is codesign saying my binary is signed correctly, but Notarization says nay-nay?

I tried upgrading to the latest XCode, but the App Store tells me it's not compatible with my version of macOS.

What next?

So there’s a lot to unpack here. You wrote:

Apparently notarytool is not compatible with Xcode 12.1, and I have to continue using altool?

We designed notarytool to be a standalone thing. While we ship it as part of Xcode, it’s fine to extract it from Xcode and use it elsewhere. So, if you’re stuck on 10.15 then it’s fine to stick with Xcode 12 for day-to-day development and use the notarytool from Xcode 13 for your notarisation.

Having said that…

I'm using macOS 10.15 (Catalina), so I can develop and reach back to as many users as possible.

Huh? There’s no reason to build on 10.15 so that you can support 10.15 [1]. Our tools support the notion of a deployment target, and current versions support deploying all the way back to 10.9. Do you need to support systems earlier than that? If not, I recommend that you upgrade macOS to something more modern.

I have been getting the --notarization-info, but it's not very enlightening:

On the contrary, I think this is very enlightening. It confirms that the problem is with the contents of your installer package, not the package itself.

Try this:

1. Find the installer package you submitted that corresponds to this error. You can confirm you have the right one by checking the SHA-256 hash in the sha256 property of the log:

   % shasum -a 256 /path/to/your.pkg
   

2. Unpack that. I generally use Pacifist for this sort of thing, but you can also do it with Apple tools (see Unpacking Apple Archives).

3. Run the following commmand against the unpacked app:

   % codesign -v -vvv --deep --strict /path/to/your.app
   

What do you see?

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

[1] Unless you’re building a KEXT, which is an entirely different kettle of fish.

Thank you for your patience and expertise. Some clarifications are in order.

[1] Backwards compatibility

My app has been running on Windows since 1995. Last year we converted it to Qt in order to run on macOS as well. We sell to consumers, who sometimes cling to older version of macOS (eg. 10.12). In order to serve this market, we currently use Qt 5.12, which wants to run on macOS 10.15 at the latest. We will move forward as soon as we think we're not leaving too many customers behind. The binary executables created with Qt run on macOS 11 and 12.

[2] notarytool and Xcode 13

I tried to upgrade from Xcode 12 to Xcode 13, and it said that Xcode 13 was not compatible with my version of macOS (10.15). Is there a different way to do it?

[3] codesign

I have run codesign -v -vvv --deep --strict /path/to/MyApp.app on my app. Every component says "validated", and the final diagnosis is:

/path/to/MyAppMyApp.app: valid on disk
/path/to/MyApp.app: satisfies its Designated Requirement

Is it necessary to unpack the app in order to validate it with codesign? Can I not run codesign directly on the .app file?

So, why is the signature OK in the local copy, but fails in the cloud?

I tried to upgrade from Xcode 12 to Xcode 13, and it said that Xcode 13 was not compatible with my version of macOS (10.15).

Through the App Store? Oh gosh, don’t do that!

Rather, download Xcode 13 from the [Downloads][downloads] area on the developer web site. See this post for the specifics.

My general advice is that you do this for all your Xcode installs, not just in this situation. See [this post]ref2], on the same thread, for an explanation as to why I recommend that.

And, as a reminder, you don’t have to use Xcode 13 for anything else. You just need to download it, unpack it, extract notarytool, and then throw that copy of Xcode away.

Is it necessary to unpack the app in order to validate it with codesign?

It’s important that you run this on a copy of the .app that you extracted from the exact installer package that you submitted to the notary service. I’ve seen numerous cases where something went wrong with the installer package creation process [1], so the .app inside the package is not the same as the .app you used to build it.

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

[1] These usually, but not always, revolve around folks using third-party tools to create their installer package.

OK, we found the problem. In the Packages project, it seems we added the App as a folder instead of a bundle. We are still using altool for now.

Why did this work for months before we started getting errors? Did Apple change its validation algorithm?

I wish Apple invested as much effort in its Notarization error diagnostic messages, as it does in its vaunted user interface. This is the antithesis of "user-friendly".

Anyway, thanks again for your help and patience.

In the Packages project

I presume you’re referring to the third-party app here? If so, you should escalate this with its developer. I can’t help you with third-party tools.

For a simple example of how to create an app installer using Apple’s productbuild tool, see Signing a Mac Product For Distribution.

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

OK, we finally got this working. Of course I don't expect you to advise on third-party apps. I just wish the Apple programmers had spent a little bit more effort on displaying more detailed, informative error messages. What we see is second-rate.

Thank you again for your help.

OK, we finally got this working.

Yay!

I just wish the Apple programmers had spent a little bit more effort on displaying more detailed, informative error messages.

I encourage you to file bugs whenever you encounter diagnostics that don’t help you quickly isolate the root cause of the problem.

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