Notarization succeeds, but gatekeeper check still fails

We're in the process of adding the signing/notarizing/staple steps as part of the CI pipelines for our various products.


For a few of our binaries (e.g. https://releases.hashicorp.com/terraform/0.12.16/terraform_0.12.16_darwin_amd64.zip), the notarization process succeeds, we get the email confirmation that the notarization process has succeeded, and we can also confirm the proccess succeeded by unzipping and running the following commands on the binary: `spctl -a -vvv -t install ${BINARY_NAME}` and `codesign --test-requirement="=notarized" -vv ${BINARY_NAME}`.


However... we still get gatekeeper failures. Binaries are all built using Golang version 1.12.13+. Any idea how to troubleshoot this // where to go from here?

Replies

Notarisation and Gatekeeper are conceptually quite different, and it’s common for a product that successfully passes notarisation to trip up Gatekeeper. Debugging such problems is tricky. You can find some hints and tips in this post.

ps You wrote:

Binaries are all built using Golang version 1.12.13+.

I was under the impression, based on this thread, that Go programs include components that are linked with an ancient macOS SDK. Is that always true? Or has this been fixed in a sufficient new version of Go?

If you get the

LogFileURL
from your notarisation request, does it flag any warnings?

pps This is unlikely to trip up Gatekeeper, but I’m just curious.

Share and Enjoy

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

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

You are trying to notarize a command line tool. I have seen a few similar threads, such as this one, and this one. These threads are pretty old. I don't know if the recent relaxation of notarization requirements would have changed their resolution. I think you could solve this by simply bundling your executable into a pkg or dmg file and notarizing that.


I don't think there are any golang issues. The thread that eskimo referenced is from someone trying to integrate a golang app with something else built on 10.8 or earlier. And I'm using the word "built" pretty loosely here.

Hey,


That has been fixed in Go 1.12.13: https://golang.org/doc/devel/release.html#go1.12


There are no warnings or errors in the LogFileURL, which is why we have been scratching our heads. We thought the signing/notarizing/stapling steps would ensure no gatekeeper errors. It does work for some products, but not for all (e.g. the terraform binary above always passes notarization but fails gatekeeper checks).


In sys logs, I don't see anything under `cmd` or `xprotect`. For `gk`, there is only one entry:

default 09:45:56.802922-0800 syspolicyd rule 11 applies - allow=1


Not really sure what to look for- there are only a few errors in the logs and they don't contain any of the keywords. Can we send you our logs?

Yeah, we are notarizing binaries (executables). This works successfully with https://releases.hashicorp.com/consul/1.6.2/consul_1.6.2_darwin_386.zip

so why wouldn't it work with the others?


When I say this works successfully, I mean that after notarization you can:


- Unzip the package

- Double click to open the executable

- Be greeted with 'consul is an app downloaded from the internet. Are you sure you want to open it?'


For other binaries, e.g. with the terraform link above, you get the error 'terraform can't be opened because the identity of the developer cannot be confirmed.'

Can we send you our logs?

I can dig into this in detail, but not in the context of DevForums. Please open DTS tech support incident, which will let me allocate the time to look at this in depth.

Share and Enjoy

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

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

Thanks. Created 724810310.

That's a 32-bit executable. It's never going to work on Catalina. But before Catalina ever attempts to execute it, it gets blocked by Gatekeeper just like the other one does. I don't know why you would think that it is Notarized. It isn't even signed at all.

I posted the wrong link: https://releases.hashicorp.com/consul/1.6.2+ent/consul_1.6.2+ent_darwin_amd64.zip

As I mentioned earlier, this is a zipfile containing a go binary that CAN be successfully signed and notarized. Feel free to test it out. The signing and notarizing are steps that I am doing locally for now- the signed/notarized binary is not live yet on the site, as the gatekeeper checks keep failing (making a new release useless).

I'm having the same issue, and I'm using an identical process to sign/notarize as another executable within my organization, however I have dylibs and that's the only difference. Everything is successful, but Gatekeeper seems to be blocking anything referencing a dylib. All the dylibs are codesigned and validated to be as such.


Also, regardless of this, 'executing' a command line from double clicking via the DMG mount still flags security warning, but runs fine from command line (when not referencing dylib), that's also pretty annoying.


Can I ask if any date on an updated Catalina with a fix for this stuff?

Can I ask if any date on an updated Catalina with a fix for this stuff?

That depends on what you mean by “this stuff”. AFAICT you’re referencing two issues here:

  • The behaviour of Terminal when you double click a command-line tool.

  • The problem where a tool referencing a dynamic library fails but a similar tool without any dynamic library references works.

I’ll address each in turn.

On the Terminal front, I have no info to share as to when that’ll be addressed (r. 58097824).

With regards your second issue, I have a suggestion for you: When you sign your command-line tool, try explicitly enabling library validation. That is, where currently you do this:

% codesign -s …stuff… -o runtime …more stuff…

Try doing this:

% codesign -s …stuff… -o runtime,library …more stuff…

Does that help?

Share and Enjoy

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

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