v26.13.0 Darwin tarball binaries are not notarized
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 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
-
难度 2/5 1-3 小时 新手友好度 65/100
nodejs/build#4539 · 1 个 reaction ·
维护者通常 2 天内回复
-
Python 3.10 EOL 2026-10-01 used in Windows可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭build-agenda
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 2 天内回复
-
Windows release nodes are offline可能已有人在做 @StefanStojanovic 于 1 天前认领。 未关闭
维护者通常 2 天内回复
-
难度 5/5 一周以上 新手友好度 25/100
维护者通常 2 天内回复
相似的 Issue
-
app: scripts status: backlog type: documentation
难度 2/5 1-3 小时 新手友好度 86/100
netbox-community/netbox-scripts#68 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 76/100
-
难度 1/5 1 小时以内 新手友好度 68/100
-
难度 1/5 1 小时以内 新手友好度 78/100
flathub/com.makemkv.MakeMKV#125 ·
-
难度 1/5 1 小时以内 新手友好度 76/100
flathub/com.jetbrains.Rider#190 ·