MacOS binary distribution is slow to start on Catalina (10.15)

[MylesBorins]

If you download the tarball of the MacOS binary and attempt to run on Catalina (10.15) there is a multi second delay until it starts. I believe that this is due to the binary not being notarized. We noticed something similar with the jstime binary

jstime/jstime#30

[mmarchini]

I thought our packages were notarized already: nodejs/node#31459, nodejs/node#29216 (comment)

[AshCripps]

Our binarys are notorized but maybe the latest build failed notorization?

[mmarchini]

@MylesBorins can you try with previous releases?

[richardlau]

I think we only notarize the pkg distribution and not the tarballs.

[MylesBorins]

AFAIK we do only notarize the .pkg. @mmarchini it is my understanding that all binary releases will now be slow on Catalina due to not being notarized, I just tested with v8.9.4 and replicated the behavior (release is 2+ years old). Although I'm a bit perplexed as to why this doesn't happen with nvm which AFAIK redistributes our binaries.

/cc @ljharb is nvm doing anything special?

[ljharb]

All nvm does is download a tarball and extract it; it's possible that using the command line doesn't check the notarization?

[MylesBorins]

@ljharb I'm using the command line, so that's what is so strange here... perhaps it is the indirection?

[MylesBorins]

OMG, it is literally just not being in the download folder 😂

Testing locally. A binary in the download folder runs super slow, one out of it doesn't WHAT!

[rvagg]

All of our binaries are signed, with entitlements baked in, even in the tarball. Notarization is for packages, you can't do it to a tarball (unless something's changed recently). Currently the notarization handling on the client side is through the installer process, when you're doing things like unpacking tarballs, or copying a file onto your computer from elsewhere (rsync, scp, etc.), you're bypassing all of that. I imagine Apple might want to change that over time to push everything through their notarization process but that's going to be tricky for them to pull off without annoying a lot of people and breaking their unix-ish usability.

[MylesBorins]

I had found this article about notarizing a golang binary, maybe it will be helpful. With that said it seems like the binaries are only slow the first time they are run in a directory that isn't ~/Downloads. Very odd.

https://www.kencochrane.com/2020/08/01/build-and-sign-golang-binaries-for-macos-with-github-actions/

[rvagg]

right, but the notarization is stapled to the package, not the binary, when you install that notarization information gets extracted and associated with where the binary is installed, tarballs bypass this, they are signed but the notarization information is not included anywhere

[MylesBorins]

@rvagg thanks for clarifying. FWIW it does not seem like the signature plays a role in subsequent runs of the binary

[ljharb]

@MylesBorins it's also possible that files downloaded by browsers are marked with an extended attribute, and that's what makes them slow? It might be worth seeing if the presence of com.apply.quarantine is the cause: https://www.jamf.com/jamf-nation/articles/59/managing-file-quarantine-attributes

[MylesBorins]

@ljharb I just downloaded via wget instead of browser, same behavior

• slow as heck start up on every load
• move the file to another directory, run it twice, not longer slow
• move it back to ~/Download and it isn't slow

[github-actions]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.