v26.13.0 Darwin tarball binaries are not notarized
維護者通常 1 天內回覆
評估
- 難度
- 4/5
- 預估耗時
- 1-2 天
- 新手友好度
- 47/100
- Issue 類型
- 缺陷
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- macos
- 領域
- release
研究方向
Start by checking the macOS release packaging job and the post-notarization check referenced in #4527, then compare how it handles the pkg and Darwin tarball binaries. Determine why the v26.13.0 arm64 and x64 tarballs lack notarization tickets while the pkg and v26.12.1 tarball are notarized. Done means both existing tarball binaries are registered with Apple without changing their SHAs.
由索引模型根據 Issue 內容生成。
描述
I was chasing down a sudden performance regression in a tool that spawns a lot of child processes, and ended up narrowing it to notarization issues with the 26.13.0 macOS tarballs.
The missing notarization sends Gatekeeper / syspolicyd into conniptions: in any process tree launched through a #!/bin/sh bin shim (so every npm/pnpm CLI), syspolicyd logs violates validation category policy. This will likely result in a block in the future and does a full trust evaluation on every process event. That adds ~3.5 ms to every posix_spawn attempt libuv makes while walking PATH, so a child_process spawn by bare name goes from ~10 ms to ~70 ms. Node 22, 24 and 26.12.1 binaries on the same machine are fine.
The bin/node binaries in the published node-v26.13.0-darwin-arm64.tar.gz and node-v26.13.0-darwin-x64.tar.gz are Developer ID signed but have no notarization ticket. node-v26.13.0.pkg is notarized and stapled. The darwin-arm64 tarball binary from v26.12.1 does have a ticket, so this looks specific to the v26.13.0 release build rather than to tarballs in general.
Quick check:
for v in v26.13.0 v26.12.1; do
curl -fsSLO "https://nodejs.org/dist/$v/node-$v-darwin-arm64.tar.gz"
tar -xzf "node-$v-darwin-arm64.tar.gz" "node-$v-darwin-arm64/bin/node"
codesign --verify --verbose=2 -R='notarized' "node-$v-darwin-arm64/bin/node"
done
This logs:
node-v26.13.0-darwin-arm64/bin/node: valid on disk
node-v26.13.0-darwin-arm64/bin/node: satisfies its Designated Requirement
test-requirement: code failed to satisfy specified code requirement(s)
node-v26.12.1-darwin-arm64/bin/node: valid on disk
node-v26.12.1-darwin-arm64/bin/node: satisfies its Designated Requirement
node-v26.12.1-darwin-arm64/bin/node: explicit requirement satisfied
Same for the x64 tarball.
This may be related to #4527, where the post-notarization check in the macOS release-pkg job intermittently reported source=Unnotarized Developer ID. The retry loop there wraps the pkg check, so the tarball binaries may have slipped past it.
As far as I understand it, fixing this doesn't require changing the published tarballs: submitting a zip of each existing bin/node to notarytool registers its CDHash with Apple, and Gatekeeper looks tickets up by hash, so the SHAs stay the same. Would that be possible so people don't have to tiptoe around 26.13.0?
(Not sure if this belongs here or in nodejs/node. Apologies if I guessed wrong.)
- 主要語言
- Jinja
- 星號
- 544
- 分支
- 184
- 平均合併
- 3 天 12 小時
- 30 天內合併 PR
- 7
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
nodejs/build 的其他 Issue
-
ci-job-request
難度 2/5 1-3 小時 新手友好度 65/100
nodejs/build#4539 · 1 則留言 · 1 個 reaction ·
維護者通常 1 天內回覆
-
Python 3.10 EOL 2026-10-01 used in Windows可能已有人在做 @MikeMcC399 於 4 天前認領。 未關閉build-agenda
難度 2/5 1-3 小時 新手友好度 65/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 1 天內回覆
-
難度 1/5 1 小時以內 新手友好度 1/100
維護者通常 1 天內回覆
-
難度 5/5 一週以上 新手友好度 25/100
維護者通常 1 天內回覆
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 65/100
murtaza-nasir/speakr#536 ·
維護者通常 1 天內回覆
-
Backport #7741 to release-1.12 (auto backport failed)可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉needs/area needs/kind needs/priority
難度 2/5 1-3 小時 新手友好度 80/100
維護者通常 1 天內回覆
-
kind/bug
難度 1/5 1 小時以內 新手友好度 88/100
falcosecurity/falco#4059 ·
維護者通常 1 天內回覆
-
bug
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆
-
documentation project-setup
難度 2/5 1-3 小時 新手友好度 70/100
維護者通常 1 天內回覆