Node: macOS Installer Requires Notarization To Be Run Under Catalina and Beyond

[enquora]

Catalina and beyond refuse to execute installer package (because of lack of notarization). It is possible to circumvent this but the procedure is not discoverable and shouldn't be expected of normal users.

It is unlikely even this current work-around will be permitted in future versions of macOS. The installer package should either conform to platform security requirements or be removed from the distributions list entirely.

[targos]

Refs: https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

[bnoordhuis]

Reading through _Customizing the Notarization Workflow_, it sounds like it'd be a major PITA to integrate with our release process. Thanks, Apple!

[MajuMadhusudanan]

I'm also facing the same problem. My package file bundle nodejs .PKG file. Now when I try to notarize my package file, apple rejects the package file saying it as invalid one. The below errors are coming in logs:

/node-v8.11.3.pkg/node-v8.11.3.pkg Contents/Payload/usr/local/bin/node",
"message": "The signature algorithm used is too weak.",

[silverwind]

These requirements do not apply to Homebrew, right? If Apple's processes prove too tricky, maybe we should make that the recommended installation method.

[enquora]

Transferring responsibility for distribution to package managers is, indeed, one answer to a fundamental requirement of the modern computing landscape.

[duncanmak]

I also ship an app that has node bundled inside the app bundle, depending on Homebrew is not a viable solution for me.

Will the Node.js foundation ship a hardened (optionally also notarized) copy of Node.js soon, in time for the release of MacOS Catalina?

[tylersmalley]

Apple has announced that Catalina will be coming in October. It would be great to hear from the OpenJS Foundation to understand if they intend on notarizing the macOS Binary.

[devsnek]

perhaps we should just recommend people install via brew/n/nvm/etc, easier to upgrade that way anyway.

[tylersmalley]

@devsnek, unfortunately, that isn't an option for folks who ship a version of Node in their software as myself and multiple folks on this thread do.

[jasontedor]

It's also relying on an assumption that Homebrew won't add the quarantine extended attribute that causes Gatekeeper to enforce signing/notarization requirements. Note that applications installed by Homebrew Cask do get the quarantine extended attribute.

[somu84]

Yea and resigning / hardening the node binary also doesn't work. As node tries to validate the signature and terminates if it's signed with any other certificate

[devsnek]

sorry I don't know much about this packaging... Why can't you just bundle the node binary itself?

[somu84]

Node binary terminates without providing any details as to why, when I try to codesign the binary with a different cert.

[MajuMadhusudanan]

Apple released macOS Catalina yesterday. Any updates regarding this issue?

[duncanmak]

I think @gdams is working on a PR to fix this.

@gdams how goes it?

[gdams]

I have a patch which enabled hardened runtime, as soon as I can confirm if the full test suite passes I will create a PR

[faijaz]

I have a patch which enabled hardened runtime, as soon as I can confirm if the full test suite passes I will create a PR

Any update on it @gdams ? When can we start integrating it with our App?

[sam-github]

ATTN: @nodejs/build -- since I don't see a ping of them (us!) in here.

[rvagg]

Thanks @sam-github, this wasn't on my radar at all either. What a pain. It looks like we're going to have more integration work to do:

If you use an automated build system, you can integrate the notarization process into your existing build scripts. The altool and stapler command-line tools (included with Xcode) allow you to upload your software to the Apple notary service, and to staple the resulting ticket to your executable.

Figuring out that process will be an interesting task for someone. Any takers? The builds primarily go through the $(BINARYTAR) and $(PKG) build targets in Makefile. In there references to tools/osx-codesign.sh and tools/osx-productsign.sh. We'll need to extend those or add new steps to make this happen.

[gdams]

@rvagg so far I have the following patch that I have been testing:

diff --git a/tools/osx-codesign.sh b/tools/osx-codesign.sh
index 6a954c737f..70403ab268 100644
--- a/tools/osx-codesign.sh
+++ b/tools/osx-codesign.sh
@@ -8,4 +8,4 @@ if [ "X$SIGN" == "X" ]; then
   exit 0
 fi

-codesign -s "$SIGN" "$PKGDIR"/bin/node
+codesign --sign "$SIGN" --entitlements tools/osx-entitlements.plist --options runtime --timestamp "$PKGDIR"/bin/node
\ No newline at end of file
diff --git a/tools/osx-entitlements.plist b/tools/osx-entitlements.plist
new file mode 100644
index 0000000000..9519157d71
--- /dev/null
+++ b/tools/osx-entitlements.plist
@@ -0,0 +1,16 @@
+  <?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+    <key>com.apple.security.cs.allow-jit</key>
+    <true/>
+    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
+    <true/>
+    <key>com.apple.security.cs.disable-executable-page-protection</key>
+    <true/>
+    <key>com.apple.security.cs.allow-dyld-environment-variables</key>
+    <true/>
+    <key>com.apple.security.cs.disable-library-validation</key>
+    <true/>
+</dict>
+</plist>
\ No newline at end of file

This will enable hardened runtime on the node binary which is the main requirement going forwards. In the OpenJDK world I have then been using electron-notarize-cli to notarize the pkg installer. The main issue going forwards is that the notarization has to be done on a mac with a full blown xcode 10 or 11 installation (not xcode build tools) as it requires the xcrun command. I'm more than happy to walk people through what I've done in the OpenJDK world so far if that helps?

[AshCripps]

@gdams Didn't you say it also requires at least 10.13 OSX machine for the notorization? and the binary itself must be built with xcode 10 command line tools otherwise the notorization fails?

[gdams]

@AshCripps yes that's correct you need a 10.13 machine with xcode 10 or above, I did some test builds and I was able to notarize a binary built on xcode 9 command line tools so maybe that requirement is slightly looser.

[directionless]

Notarization isn't too bad -- the biggest issue is that it's an asynchronous process. Because of it, my workflow ends up having an intermediary staging step.

Anyhow, the core commands to notarize are:

xcrun altool --username $APPLEID --password @env:N_PASS --asc-provider $TEAMID --notarize-app --file $FILE  --primary-bundle-id $BUNDLEID

xcrun altool --username $APPLEID --password @env:N_PASS --asc-provider $TEAMID  --notarization-info $REQUEST_GUUID 

staple $FILE

These commands can return xml which is reasonably parsable

[rvagg]

Trying to get my mental model sorted out for this. My naive understanding here is that the binary gets shipped to Apple, who sprinkle holy water on it, bless it, and send it back to us and then we can publish it? What's the delay in that process? How much extra time would we be adding to the release process if we can fully automate the steps? And how reliable is it? Are we going to have to deal with regular, or even occasional failures because we're introducing a complex external dependency?

[directionless]

@rvagg As I understand it, that's half correct.

1. Binary is shipped to apple (caveat: not just binary, I'm unclear on all the nuance there)
2. Apple scans it, and decides it's legit
3. Apple does _not_ send anything back. Instead, apple's servers know the hash is legit
4. You can download an attach a "ticket" showing the application is good. This is the staple process. (This is recommended for things that support it)

My experience so far, is that uploading to apple for scanning is 1-10 minutes depends a bit on binary size. The wait time on notarization has been 1-30min (visible with that --notarization-info command)

As I understand the requirements today, as long as you're using the public APIs, and the hardened runtime, you should be fine. But, I cannot guess how the requirements will change over time. Apple is Apple.

[mitchellh]

Hello! I've been helping our company (HashiCorp) work through this, even though we aren't Node users, and I wanted to drop a few things here that may be helpful. I've also been spending quite a lot of time researching this so if there are any questions I'd be happy to answer them. Like I said, I'm not a Node user or really part of this community, but from a general FOSS perspective, I'm happy to be of service.

What @directionless said is correct. For step 1, Apple supports only four formats dmg, pkg, app, or zip. The one caveat with zip is that it does _not_ support stapling (step 4 of what @directionless said), so users would need to have internet on first use (of any exec of the an executable, not the unzipping action) to verify the notarization.

If you're looking to automate this to some extent, I've built a CLI to do that (language agnostic): https://github.com/mitchellh/gon It probably doesn't have the features the Node project needs to fully integrate it but I'm happy to help with that. Ultimately, I don't care if you use my tool, but the source code may be helpful in better understanding how this works. One thing I found building that tool is that therea re various transient errors to be aware of that are safe for retries.

Good luck! 🚀

[rvagg]

Re https://github.com/nodejs/TSC/issues/773#issuecomment-549671458 @ljharb

Does this only apply to the installer? or would it also affect version managers like nvm?

Notarization is for Mac apps, installer packages, and kernel extensions that are signed with Developer ID. I believe that excludes our plain executables and scripts for now (node is not an "app", but we ship a .pkg which is why we're hit with this) but I'm reading this a step toward unifying their iOS and macOS ecosystems so I wouldn't be surprised to see increasing difficulties bypassing this for arbitrary executables over time and we should prepare for that.

Homebrew would be the hardest hit were there any changes to this and I imagine they'd be a lead to follow in such a case.

[directionless]

Homebrew would be the hardest hit were there any changes to this and I imagine they'd be a lead to follow in such a case.

At least today, gatekeeper only applies to things that have the quarantine bit set. This is an extended attribute set by web browsers and similar. Update frameworks, curl, and presumably homebrew complete bypass this.

(No clue what future OSes will bring)

[mattbishop]

I thought I'd add a screenshot from Catalina so you can see what the experience is like. I agree with others, relying on homebrew or macports to solve this will not work. Many, many students learn node, and they are not going to install a package manager to get node.

Curious, is it hard to put Node in the Mac App Store?

[MajuMadhusudanan]

Is this issue fixed on latest pkg file? Apple will enforce app notarization for Catalina in February .

https://appleinsider.com/articles/19/12/23/apple-will-enforce-app-notarization-for-macos-catalina-in-february

[MajuMadhusudanan]

Is this issue fixed on latest pkg file? Apple will enforce app notarization for Catalina in February .

https://appleinsider.com/articles/19/12/23/apple-will-enforce-app-notarization-for-macos-catalina-in-february

i still see warnings when i integrate v12.14.0 build into our package file. Apple reporting warnings for the below executables (term-size and node).

"issues": [
{
"severity": "warning",
"code": null,
"path": "Sample.pkg Contents/Payload/Library/Application Support/iManage/Script/node-v12.14.0.pkg/npm-v6.13.4.pkg Contents/Payload/usr/local/lib/node_modules/npm/node_modules/term-size/vendor/macos/term-size",
"message": "The binary is not signed.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "warning",
"code": null,
"path": "Sample.pkg Contents/Payload/Library/Application Support/iManage/Script/node-v12.14.0.pkg/npm-v6.13.4.pkg Contents/Payload/usr/local/lib/node_modules/npm/node_modules/term-size/vendor/macos/term-size",
"message": "The signature does not include a secure timestamp.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "warning",
"code": null,
"path": "Sample.pkg Contents/Payload/Library/Application Support/iManage/Script/node-v12.14.0.pkg/npm-v6.13.4.pkg Contents/Payload/usr/local/lib/node_modules/npm/node_modules/term-size/vendor/macos/term-size",
"message": "The executable does not have the hardened runtime enabled.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "warning",
"code": null,
"path": "Sample.pkg Contents/Payload/Library/Application Support/iManage/Script/node-v12.14.0.pkg/node-v12.14.0.pkg Contents/Payload/usr/local/bin/node",
"message": "The signature algorithm used is too weak.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "warning",
"code": null,
"path": "Sample.pkg Contents/Payload/Library/Application Support/iManage/Script/node-v12.14.0.pkg/node-v12.14.0.pkg Contents/Payload/usr/local/bin/node",
"message": "The executable does not have the hardened runtime enabled.",
"docUrl": null,
"architecture": "x86_64"
}
]

[andrewdstrain]

Yes, I'm attending Woz U and downloaded LTS (12.14.1) and Current (13.6.0) today and it gave the error. I'm going to use MacPorts to install but, you're right, the method presented in class says to download it from the website.

[idanwork]

I just experienced the same issue, on 10.15.2,
After downloading pkg for both Latest & LTS version.

For me "right click" -> open gave me another dialog that allows to continue.

Hope it helps anyone

[MajuMadhusudanan]

Apple made this as mandatory now. Earlier when we package nodejs package file into our package file, Apple was reporting those rules as warnings. Now they started showing it as errors. So the whole notarization process will fail for people who package/bundle NodeJS package file into their setup.

There is no way to get rid of these errors without code-signing nodeJS binaries (term-size, node) with hardened runtime enabled.

"issues": [
{
"severity": "error",
"code": null,
"path": "Sample.zip/release/Sample.pkg/Sample.pkg Contents/Payload/Library/Application Support/Sample/Script/node-v12.14.0.pkg/npm-v6.13.4.pkg Contents/Payload/usr/local/lib/node_modules/npm/node_modules/term-size/vendor/macos/term-size",
"message": "The binary is not signed.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "error",
"code": null,
"path": "Sample.zip/release/Sample.pkg/Sample.pkg Contents/Payload/Library/Application Support/Sample/Script/node-v12.14.0.pkg/npm-v6.13.4.pkg Contents/Payload/usr/local/lib/node_modules/npm/node_modules/term-size/vendor/macos/term-size",
"message": "The signature does not include a secure timestamp.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "error",
"code": null,
"path": "Sample.zip/release/Sample.pkg/Sample.pkg Contents/Payload/Library/Application Support/Sample/Script/node-v12.14.0.pkg/npm-v6.13.4.pkg Contents/Payload/usr/local/lib/node_modules/npm/node_modules/term-size/vendor/macos/term-size",
"message": "The executable does not have the hardened runtime enabled.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "error",
"code": null,
"path": "Sample.zip/release/Sample.pkg/Sample.pkg Contents/Payload/Library/Application Support/Sample/Script/node-v12.14.0.pkg/node-v12.14.0.pkg Contents/Payload/usr/local/bin/node",
"message": "The signature algorithm used is too weak.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "error",
"code": null,
"path": "Sample.zip/release/Sample.pkg/Sample.pkg Contents/Payload/Library/Application Support/Sample/Script/node-v12.14.0.pkg/node-v12.14.0.pkg Contents/Payload/usr/local/bin/node",
"message": "The executable does not have the hardened runtime enabled.",
"docUrl": null,
"architecture": "x86_64"
}
]

[rvagg]

this is being actively worked on in https://github.com/nodejs/node/pull/31459 (working notarization) and in our build infrastructure (still pending hardware and software upgrades)

[jeremy-j-ackso]

For me "right click" -> open gave me another dialog that allows to continue.

This worked for me as well. Not likely a permanent solution, but good for the short term.

[VidhuMitra]

Hi, Is there any update on this issue fix?

[nimit95]

I was able to notarize node application, I compressed it in the zip and notarized it using the steps mentioned here. https://medium.com/@nimit95/fix-macos-catalina-caused-app-failures-1f9a05d2b0ec

[dimaqq]

Now it's a matter of rolling this into the build process ‼️

[sportshead]

Why not just package sudo-prompt with the installer and run the package scripts with that?

[MylesBorins]

This has gone out in v13.12.0.

We'll aim to get it in the next two LTS releases if there are no regressions reported

[AshCripps]

This should be closed now, the latest 10.x and 12.x releases went out yesterday with notorization right?

[richardlau]

I'll leave this pinned for a few days for visibility. Node.js 10.20.0, 12.16.2 and 13.12.0 are all notarized.