search

nodejs / build

Better build and test infra for Node.
502 stars 165 forks source link

macOS refuses to start `node` when downloaded from the tarball #3538

Open targos opened 8 months ago

targos commented 8 months ago

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

Screenshot 2023-10-18 at 18 36 16

Originally posted by @mistic in https://github.com/nodejs/build/issues/3385#issuecomment-1769027175

Repro:

targos commented 8 months ago

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 commented 8 months ago

This affects all existing releases.

UlisesGascon commented 8 months ago

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 commented 8 months ago

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

UlisesGascon commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

Before you upgrade your machine, can you confirm:

targos commented 8 months ago

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 commented 8 months ago

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

richardlau commented 8 months ago

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: https://github.com/nodejs/build/issues/2188#issuecomment-604181411

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 commented 8 months ago

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)

Screenshot 2023-10-24 at 11 30 17

targos commented 8 months ago

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

This was in x64

UlisesGascon commented 8 months ago

I will create a PR to try notarize the tarballs

kwasimensah commented 6 months ago

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 commented 6 months ago

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

UlisesGascon commented 6 months ago

@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 commented 2 months ago

I am actively working on this during the weekend. I will make an update asap :+1:

UlisesGascon commented 2 months ago

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):

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:

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

richardlau commented 2 months ago

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 commented 2 months ago

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