Notarizing executables for Catalina?

I am trying to solve an issue with one of our products that is not distributed over the Mac App Store.


This product is an extension in Adobe’s video cutting app “Premiere Pro”. The extension (which is basically an HTML page) is launching a command line executable. That’s when Gatekeeper chimes in and gives an error saying that the app needs to be updated by the developer.


For context: the executable is written in Go-lang (for cross platform compatibility).

After the binary was built, I am code signing it with our working Apple Developer ID certificate:


$ codesign -s "Developer ID ..." -v /path/to/HelperExec


Then I verify:


$ codesign --verify --deep --strict --verbose=2 /Users/workingThomas/develop/adobe-client/bin/HelperExec
/path/to/HelperExec: valid on disk
/path/to/HelperExec: satisfies its Designated Requirement



Then I simulate Gatekeeper


$ spctl --assess --verbose=4 /path/to/HelperExec
/path/to/HelperExec: rejected (the code is valid but does not seem to be an app)



And of course, the binary can not be executed in the Terminal without getting the Gatekeeper dialog. There is no documentation how to notarize executables that are not embedded in an app package.


Can someone help or point me in the right direction?

How can we avoid Gatekeeper to bother our end-users?


Thanks,

Thomas

Replies

Just zip it and send it to the notary service.

The difference is that you won't be able to staple a ticket to the command line executable.

How do you distribute your extension? Most folks distribute non-app products as either a disk image (

.dmg
) or an installer package (
.pkg
), in which case it’s best to sign everything, including the outermost container, and then notarise and staple the outermost container. The resulting ticket will cover all executable code within that container, including your command-line tool.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Sorry for the late reply, just saw your answers here.

I haven't gotten a notification even if I am following this thread.


@eskimo

The extension is distributed over the Adobe Exchange. Therefore I have to "package" the extension using the ZXPSignCmd command line tool. An extension is nothing but a folder with subfolders and mostly HTML/JS files. In one of the subfolders is the executable for mac.


ZXPSignCmd does the following:

- signs the extension folder and it's contents

- zip archives the folder

- renames the zip archive's file extension to ".zxp"

- as a result I have a single file to distribute like our latest extension:
https://app.frame.io/presentations/cb404a0b-70ed-4ba8-a230-0f48f52bdcc8


The zxp extension can be installed in two ways:

- by "acquiring" the extension on the Adobe Exchange, the Adobe CC desktop app will automatically install it (similar concept to the Mac App Store)

- using the Adobe's command line tool ExManCmd, which allows mostly enterprise users to batch install the extension using the Shell


So everything is already signed but not with codesign and not using our Apple Developer ID. Does it makes sense to notarize the zxp extension file then?


I'll try what @galad87 said.

Wow, that’s quite a kettle of fish you’ve got boiling there.

First up, it’s definitely possible to notarise your tool by putting it in a container of your choice and then submitting that for notarisation. You should definitely do that, at least in the interim.

Second, there’s no way to staple the resulting ticket to your product. This is not great, but neither is it the end of the world. If the trusted execution system on macOS needs the ticket, it can download it from Apple. It caches the ticket, so as long as the Mac is online the first time this happens you should be fine.

Third, you really need to escalate this to the folks responsible for this distribution channel. They need a long term plan for dealing with notarisation.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

"First up, it’s definitely possible to notarise your tool by putting it in a container of your choice and then submitting that for notarisation. You should definitely do that, at least in the interim."


I want to make sure I get this right. Does that mean I can send the zxp extension file to the notarization service?


Would the following also be an alternative:

As suggested by galad87, what if I codesign and then zip just the executable, notarize it and staple the tickets to the executable before packaging everything with ZXPSignCmd for distribution?


If found this exerpt from this Apple doc:

"While you can notarize a ZIP archive, you can’t staple to it directly. Instead, run stapler against each individual item that you originally added to the archive. Then create a new ZIP file containing the stapled items for distribution. Although tickets are created for standalone binaries, it’s not currently possible to staple tickets to them."

Does that mean I can send the zxp extension file to the notarization service?

I’m not sure what the notarisation service will make of a zip archive with the

.zxp
extension. However, if the
.zxp
file is actually a zip archive under the covers, you could just change the extension back to
.zip
and submit that.

It’s worth a shot anyway (-:

If that doesn’t work, you could just create your own zip archive containing your command-line tool and notarise that.

As suggested by galad87, what if I codesign and then zip just the executable, notarize it and staple the tickets to the executable before packaging everything with ZXPSignCmd for distribution?

Yeah, kinda like that, except for the stapling part. You can’t staple a ticket to a ‘*****’ command-line tool because there’s nowhere for

stapler
to put the ticket in that case.

In fact, given your distribution model there’s no way for you to include a ticket at all. In the unlikely event that the trusted execution system needs a ticket while the Mac is offline, you’ll run into problems. This is why I suggested that you escalate this to the folks running your distribution model.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

As I figured out today, it seems that this issue has already been escalated at Adobe. They are working on their installer tool ExManCmd. I have big hopes that it works.


Thanks Eskimo, you've been very helpful!