Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

v26.13.0 Darwin tarball binaries are not notarized

Đang mở
  • Có gì không ổn?
#4,545 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
47/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
macos
Lĩnh vực
release

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
Jinja
Star
544
Fork
184
Merge trung bình
3 ngày 12 giờ
Pull request đã merge (30 ngày)
7

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của nodejs/build

Tất cả issue của nodejs/build

Issue tương tự

Thêm issue về Release

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.