Notarize: The staple and validate action failed! Error 73

I'm trying to staple a validation ticket to an exe file that is already notarized. The process ended with the following error:

Downloaded ticket has been stored at file:///var/folders/bj/ry08v0694972s03cswkq5md80000gq/T/7f1a34f0-8628-4157-92b0-b59cebe70951.ticket. Could not remove existing ticket from file:///Users/efi-admin/Downloads/ActualSignedFile/Contents/CodeResources because an error occurred. Error Domain=NSCocoaErrorDomain Code=512 "“CodeResources” couldn’t be removed." UserInfo={NSUserStringVariant=( Remove ), NSFilePath=/Users/efi-admin/Downloads/ActualSignedFile/Contents/CodeResources, NSUnderlyingError=0x600000151e90 {Error Domain=NSPOSIXErrorDomain Code=20 "Not a directory"}} The staple and validate action failed! Error 73.

The above was captured using the verbose option of the cmd...

Among the response, I can see the ticket: fields = { signedTicket = { type = BYTES; value = "czhjaAEAAADxBQAALQAAADCCBe0wggL/MIICpKADAgECAghWLFU2G59vVTAKBggqhkjOPQQDAjByMSYwJAYDVQQDDB1BcHBsZSBTeXN0ZW0gSW50ZWdyYXRpb24gQ0EgNDEmMCQGA1UE.... (partial)

I need help to properly understand what is this cmd doing as the issue might be permissions one.

The path mentioned above under /ActualSignedFile:

/ActualSignedFile/Contents/CodeResources

Does not exist. Is that the cmd wants to create it?

Is there any way to manually attach the ticket to the file, given the fact that is printed in verbose mode?

Thanks!

Any help will he highly appreciated!

Accepted Reply

First up, I strongly recommend that you not use your Downloads folder for day-to-day work. Downloads is protected by MAC, and that can cause all sorts of weird problems. See On File System Permissions for more about MAC.

Having said that, that doesn’t appear to be the cause of this issue. You wrote:

I'm trying to staple a validation ticket to an exe file that is already notarized.

I presume that this is a command-line tool, that is, a single standalone executable. If so, you won’t be able to staple a ticket to it. Stapling only works for bundled code (typically apps), installer packages, and disk images.

Stapling is not an absolute requirement, so you could just skip this step. See The Pros and Cons of Stapling for more about that.

In most cases, however, you can staple your ticket by adopting the right packaging format. Mac users expect to receive their software in one of three containers: zip, disk image, or installer package. Two out of three of those support stapling. So, my advice is that you package your tool into a container that supports stapling, notarise that container, and then staple that.

For detailed advice, see Packaging Mac Software for Distribution.

One last note: Some users attempt to run command-line tools by double clicking them in the Finder. Doing this triggers a Gatekeeper bug; see the Tool Blocked by Gatekeeper section of Resolving Gatekeeper Problems. If you think your users are likely to do this, you can avoid this bug by distributing your tool in an installer package.

Share and Enjoy

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

Replies

First up, I strongly recommend that you not use your Downloads folder for day-to-day work. Downloads is protected by MAC, and that can cause all sorts of weird problems. See On File System Permissions for more about MAC.

Having said that, that doesn’t appear to be the cause of this issue. You wrote:

I'm trying to staple a validation ticket to an exe file that is already notarized.

I presume that this is a command-line tool, that is, a single standalone executable. If so, you won’t be able to staple a ticket to it. Stapling only works for bundled code (typically apps), installer packages, and disk images.

Stapling is not an absolute requirement, so you could just skip this step. See The Pros and Cons of Stapling for more about that.

In most cases, however, you can staple your ticket by adopting the right packaging format. Mac users expect to receive their software in one of three containers: zip, disk image, or installer package. Two out of three of those support stapling. So, my advice is that you package your tool into a container that supports stapling, notarise that container, and then staple that.

For detailed advice, see Packaging Mac Software for Distribution.

One last note: Some users attempt to run command-line tools by double clicking them in the Finder. Doing this triggers a Gatekeeper bug; see the Tool Blocked by Gatekeeper section of Resolving Gatekeeper Problems. If you think your users are likely to do this, you can avoid this bug by distributing your tool in an installer package.

Share and Enjoy

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

thanks for such a very useful points!

Once notarized, the app still reject to run in MACs with T2, but oddly to me, it runs OK in older Macs. Make sense?. If so, I guess the Gatekeeper behaves differently on old Intel Macs vs T2 ones...

How old is that GateKeeper problem? And when is it expected to be solved?

Again, thanks for all your help!

How old is that GateKeeper problem?

Very.

And when is it expected to be solved?

I can’t predict the future.

This is only relevant if you double click the tool in the Finder. If you run the tool from Terminal, Gatekeeper does the right thing.

Once notarized, the app still reject to run in MACs with T2, but oddly to me, it runs OK in older Macs. Make sense?

No. Something else is going on there.

See Testing a Notarised Product for my advice on how to test notarisation. My experience is that this approach yields consistent results.

Also, when you say “app” you mean command-line tool, right? Because an actual app, one with a bundle structure and a .app extension, is not affected by this issue.

Share and Enjoy

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

Thanks Quinn!, as usual, very informative..

Now, I'm trying to convert my exe file (python compiled for MacOS) in an App, so I can avoid the Gatekeeper issue. Following instruction I read, I create a directory (named MyApp.app) inside Desktop folder. on the said MyApp.app dir, I create a Contents directory, and inside the latter, MacOS (where the exe file was placed) and Resources (where the icon was placed). Inside the Contents directory, besides Dirs MacOS and Resources, I put the file Info.plist.

When using the comand pkgbuild, it threw the error: MyApp.app is NOT a valid bundle component (using destination path"/Users/<user>/Desktop").

Could you please, point me to where I can learn about this error and on how to do an App from an exe file?

One more: I tested my App in a completely new Mac (I meant, new to the App, actually it was an Intel Non T2 Mac build in year 2017). To my surprise, the non-signed app runs perfectly while the Signed-Notarized one throw an execution error complaining about the signature (both surpass Gatekeeper with no complain whatsoever from it side). However, in an another non T2 Mac affiliated to my icloud address, both worked well at the first time (likewise, surpassing Gatekeeper).

So far, the only complain from Gatekeeper came from an Intel T2, in which case, I needed to disabled it. But once I did that, both the signed-Notarized and the non-signed run perfectly well as expected. (tests on M1/M2 pending). [note: when I say non-signed, I meant non signed according to Apple rules. PyInstaller somehow sign the file at the time of compilation (is a very limited signature, much less informative compared to Apple's)].

As the facts are non coherent (the signed App works well in some macs and not in others with the same hardware) what would be your suggestion to clarify these issues?

Once more time, THANKS!! for all your help!

IMPORTANT Stop working within your Desktop folder. As I mentioned above, it will cause weird problems. Rather, create a directory in your home directory, say “Programming”, and do you work there. And if you want easy access to that from the Desktop, create an alias.

Now, I'm trying to convert my exe file … in an App

I’d like to clarify your goals here. So far I’ve been assuming that you’re creating a command-line tool, that is, a program that:

  • The user runs from the Unix shell (Terminal, SSH, and so on)

  • Which interacts with the user using stdout, stdin, and stderr

Is that correct?

Share and Enjoy

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

Quinn, once more time, thank you very much for your help!

What I am trying to achieve is to distribute a single file compiled exe (originally a python script compiled using pyinstaller) directly to certain customers. (it is an exe file, that runs by open it or double click on it from Finder).

So, the idea is to have the said exe as an App available to download or otherwise, send it over to selected users. We already have a Zip file with the exe inside, duly signed and notarized (I meant, we went to the process to get an accepted notarization from Apple using exclusively cmd tools).

When I say "convert it to an app" (sorry for not use the appropriate language is that is the case) I meant to have the app opened by double clicking in the downloaded exe file (once the downloaded Zip is opened). Please, point to me to info on how to do this properly. On the other hand, as using zip files are not compatible with stapling, we would prefer to distribute the app using pkg or dmg, whichever is appropriate and more straight forward. (Any hints will be highly appreciated!)

The exe should work as follows: once double click on it, it opens a terminal session in which the user need to input a series of information interactively. Once it finished, the exe executes a series of processes within the terminal. and produce certain reports. It will finish when the user says so using the console (by input certain letter on the keyboard when prompted for it)

I hope to have replied properly to your questions and now my goals are clear.

Another issue I am confronting, is that the exe runs in some equipment, but not in others when using the signed-notarized version, while the unsigned version (after being authorized and bypass Gatekeeper) runs everywhere (M1/M2 and Intel with or without T2). The issue seems to be related to the signature. Somehow the process I went through for signing causes a kind of corruption in some binaries. Any suggestion or comment on this?

Thanks!

it is an exe file

You keep using that terminology but it doesn’t really make sense on macOS. macOS has:

  • Apps — These ship as a .app bundle, are run from the Finder, appear in the Dock, have a menu bar, display their UI in windows, and so on.

  • Command-line tools — These ship as a single Mach-O executable file, are run from Terminal, and interact with the user with stdin, stdout, and stderr.

It’s possible to double click a command-line tool in the Finder, in which case it opens in Terminal. Terminal respondes by opening a new window and running the tool in that. The primary caveat with this technical is the above-mentioned Tool Blocked by Gatekeeper bug.

The exe should work as follows: once double click on it, it opens a terminal session in which the user need to input a series of information interactively.

This is not a model that’s natively supported by macOS. To make this work you’d have to ship an app that acts like Terminal, that is, it:

  • Create the UI, including a menu bar

  • Displays a terminal-ish window that the user can interact with

  • Runs your actual code as a child process, with stdin, stdout, and stderr connected to a pseudo terminal that routes the I/O the its terminal-ish window

This is possible to be, but it’s a lot of work. There might be standard third-party wrappers that support this — indeed, it might be possible to get PyInstaller to do this — but that’s not something I maintain expertise in. You’ll have to research that aspect of it yourself.

Once you have one of these things, an app or a command-line tool, the path forward for signing and notarising is relative clear.

Share and Enjoy

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