macOS refuses to start node when downloaded from the tarball

[targos]

When I download that release into a arm mac running Sonoma 14.0 and then try to run ./bin/node using the terminal I'm getting a security notice that you can check in the following image

Originally posted by @mistic in #3385 (comment)

Repro:

• Download the tarball with a web browser, for example using https://nodejs.org/download/release/latest-v18.x/node-v18.18.2-darwin-x64.tar.xz
• cd ~/Downloads && tar xf node-v18.18.2-darwin-x64.tar.xz
• Try to run ./node-v18.18.2-darwin-x64/bin/node

[targos]

It seems that notarization is now necessary for the plain binary file. I haven't found any reference to that in the macOS release notes.

$ syspolicy_check distribution node-v21.0.0-darwin-arm64/bin/node
App has failed one or more pre-distribution checks.
---------------------------------------------------------------
Notary Ticket Missing
    File: /Users/mzasso/Downloads/node-v21.0.0-darwin-arm64/bin/node
    Severity: Fatal
    Full Error: A Notarization ticket is not stapled to this application.
    Type: Distribution Error

[targos]

This affects all existing releases.

[UlisesGascon]

Thanks for the research, @targos. I was not able to test it as I don't have an ARM Apple machine available that supports Sonoma. I can create a PR to try adding the tarball to the notarization following this discussion (https://developer.apple.com/forums/thread/651759) that recommends compressing it as a .zip file and checking if the tarball was properly notarized.

[targos]

Ah, this doesn't affect x64, only arm64 ?

[UlisesGascon]

This affects all existing releases.

Do we want to make this notarization retroactively to all the affected binaries? I believe that the notarization process is independent from the distribution, so we can do a long running script that downloads the binaries and notarize them one by one. So in few hours/days we can potentially solve this.

[UlisesGascon]

Ah, this doesn't affect x64, only arm64 ?

I didn't tested on Sonoma, but I can upgrade my machine and test it. I will ask in Slack if maybe someone can test it :)

[targos]

Before you upgrade your machine, can you confirm:

• Your macOS version
• That the reproduction steps I put in the OP do not end up in an error dialog for you

[targos]

This affects all existing releases.

Do we want to make this notarization retroactively to all the affected binaries? I believe that the notarization process is independent from the distribution, so we can do a long running script that downloads the binaries and notarize them one by one. So in few hours/days we can potentially solve this.

Is it possible to notarize without changing the contents of the binaries?

[targos]

I just tested the reproduction steps with macOS Ventura 13.5.2 and it also happens with that version.

[richardlau]

I'll defer to people more familiar with mac's but when we first had to do notarization we were unable to notarize the tarball: #2188 (comment)

https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution#3087722 says:

You can notarize an existing disk image, installer package, or ZIP archive containing your app.

[UlisesGascon]

Ah, this doesn't affect x64, only arm64 ?

I just tested the reproduction steps with macOS Ventura 13.5.2 and it also happens with that version.

I was trying to reproduce it in x64 and there is no error 🧐. I am using CPU: Intel Core i9 OS: 13.4.1 (22F82)

[targos]

I just tested the reproduction steps with macOS Ventura 13.5.2 and it also happens with that version.

This was in x64

[UlisesGascon]

I will create a PR to try notarize the tarballs

[kwasimensah]

I'm looking into some issues with Node and trusted execution and this page was helpful https://forums.developer.apple.com/forums/thread/706442

TLDR; curl/wget dont' set the quarantine bit but the browser does. The quarantine bit is makes the OS ask for permission on first run.

It seems like if the quarantine bit isn't sit you can still run the executable but can run into issues down the line (I'm running into the equivalent of https://developer.apple.com/forums/thread/663456 with node binaries in a build tool)

[mhdawson]

@UlisesGascon wondering if you'd gotten around to a PR, can't remember if I saw one go by or not.

[UlisesGascon]

@UlisesGascon wondering if you'd gotten around to a PR, can't remember if I saw one go by or not.

Not yet, I was focus on the 20.11.0 release. I plan to start working on this asap.

[UlisesGascon]

I am actively working on this during the weekend. I will make an update asap 👍

[UlisesGascon]

Ok! I made some progress on the topic, but I will need help to really do all the tweaks needed in Jenkins. So, let me summarize a bit the changes.

What I did?

1. I updated the original notarization script to include tarball support (using the trick to compress the tarballs to zip format for the submission and then unzip them), see PR #52610.
2. Changed the regex that condition this step in the experimental pipeline (search for https://raw.githubusercontent.com/UlisesGascon) from osx1(\d|\d\d\d)-release-pkg to osx1(\d|\d\d\d).* in order to enable this step for all the macOS machines.

Where I need support?

I am having some issues to follow all the CI steps, so it will be nice to have a better understanding and potentially suggestions on how we can integrate this new process.

The current release output for MacOS is composed by 5 binaries (see):

• node-v21.7.3-darwin-arm64.tar.gz
• node-v21.7.3-darwin-arm64.tar.xz
• node-v21.7.3-darwin-x64.tar.gz
• node-v21.7.3-darwin-x64.tar.xz
• node-v21.7.3.pkg

Today only node-v21.7.3.pkg is notarized, so our objective is to notarize the other 4. So, I made some changes in the script (see: PR #52610) from notarizing only .pkg to do a loop searching for existing files with our relevant extensions pkg tar.gz tar.xz (see) and then I use the zip compression and decompression trick to do a valid submission. But so far, the compressed files where not detected.

What I am not sure about is how the pipeline and other scripts interact right now. As far as I can see from the logs, only the .pkg file is available when running this script:

• osx11-arm64-release-tar
• osx11-x64-release-tar
• osx11-release-pkg

I would appreciate some guidance or a small pairing session (cc: @nodejs/build-infra) :-)

[richardlau]

What I am not sure about is how the pipeline and other scripts interact right now. As far as I can see from the logs, only the .pkg file is available when running this script:

* [osx11-arm64-release-tar](https://ci-release.nodejs.org/job/testing-new-osx-notarization-ojs+release/nodes=osx11-arm64-release-tar/lastBuild/console)

* [osx11-x64-release-tar](https://ci-release.nodejs.org/job/testing-new-osx-notarization-ojs+release/nodes=osx11-x64-release-tar/lastBuild/console)

The tarballs are there -- they're being uploaded via scp. It looks from the job output that the notarization script is complaining about ARCHTYPE?

[richardlau]

Also maybe you're not accounting for the pkg files not containing darwin-<arch> in the filename as the pkg file is a universal, macOS only file.
e.g. for Node.js 21.7.3:
node-v21.7.3-darwin-arm64.tar.gz 10-Apr-2024 15:55 43008394
node-v21.7.3-darwin-arm64.tar.xz 10-Apr-2024 15:56 22304676
node-v21.7.3-darwin-x64.tar.gz 10-Apr-2024 13:40 44862252
node-v21.7.3-darwin-x64.tar.xz 10-Apr-2024 13:41 24330828
node-v21.7.3.pkg 10-Apr-2024 15:52 76760797