Repository navigation
Check and backfill notarization of darwin tarballs - #4549
Open
UlisesGascon wants to merge 1 commit into
Open
UlisesGascon wants to merge 1 commit into
UlisesGascon wants to merge 1 commit into
Conversation
Add tools/macos-tarball-notarization.sh. Given release versions, or --all-supported for the lines currently in their support window, it downloads the darwin tarballs, verifies the bin/node signature and asks Apple's Gatekeeper ticket service, by code directory hash, whether a notarization ticket exists. That is the lookup macOS itself performs; `codesign --verify -R=notarized` only reads the local ticket cache and reports a notarized binary as unticketed on a machine that never fetched its ticket. A failed lookup is reported as such, never as a missing ticket. With --submit it zips and submits the binaries that lack one through the NODE_RELEASE_PROFILE keychain profile, requires Apple's Accepted verdict, and waits for the ticket. --latest N limits the run to the N most recent releases per line, since every check downloads a tarball. Notarizing a published binary does not modify it, so checksums stay valid; this is how already shipped tarballs get backfilled. Document in release-overview.md how macOS signing and notarization are wired, that tarball binaries usually receive a ticket only days after a release when third parties notarize apps that bundle them, that the NOTARIZATION_* variables in iojs+release must be exported on the tarball axes too, and how to check and backfill a release. Describe in jenkins-jobs.md the scheduled ci-release job that runs the script nightly, which both backfills and detects a tarball axis that stopped notarizing. Note in the orka README that pkg and tarball nodes share the release image. Refs: nodejs/node#67140 Refs: nodejs/node#67143 Refs: #3538 Refs: #4545 Assisted-by: Claude Assisted-by: Codex Signed-off-by: Ulises Gascon <ulisesgascongonzalez@gmail.com>
Member
Author
|
After nodejs/node#67140 (comment) probably the pipeline is not needed, I am checking how many versions actually require submission. Based on that we can decide how relevant is this |
Member
Author
|
Full inventory done. I ran The 42 tarballs without a ticketNote: I ignored EOL lines, but happy to check if makes sense. IMO we can just ssh into the machine and submit them and remove the new pipeline idea from the table. WDYT? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Build side of nodejs/node#67140, pairs with nodejs/node#67143. Adds a script that checks the published darwin tarballs for an Apple notarization ticket and, with credentials, submits the ones that lack it, so already shipped releases get fixed in place without changing any artifact or checksum. Documents how signing and notarization are wired across the pkg and tarball jobs and defines a nightly ci-release job to run it.
What the script does, per tarball:
--all-supported --latest Nfrom the Release schedule andindex.json. Releases only.bin/node.codesign --verify --strict. Invalid: report, no submission.codesign -R=notarizedonly reads the local cache). Ticket present: skip.--submit: report the missing ticket.--submit: check the signing team, zip withditto,notarytool submit --waitthrough theNODE_RELEASE_PROFILEkeychain profile, require Apple'sAcceptedverdict (print the notary log otherwise), poll until the ticket is visible.Testing: check mode was run on an Intel Mac in all three forms, explicit version,
--all-supported --latest 3, and a nightly viaNODE_DIST_URL. The Apple ticket lookup was verified against 18 published tarballs (table below) and the CDHash extraction againstcodesign -dvvv; the script's check mode on the Mac reports the same 15 present and 3 missing. The submit path was exercised with stubbedcodesign/ditto/notarytoolonly. I have no Apple credentials locally, so the plan is to try--submitafter merge over SSH on an ephemeral release-ci VM, which has the keychain profile, and shape the script from whatever that first session surfaces. Expect a follow-up PR.Ticket status of the 18 most recent tarballs, from Apple's ticket service, 2026-10-31
Our own
.pkgtickets are created within a minute of the pkg signature. Tarball tickets appear days later and get re-issued often, consistent with third parties notarizing apps that bundle our signedbin/node. The first days after a release, and any version nobody bundles, are uncovered.Actions for release admins, not in this diff: Backfill the published tarballs (three binaries today: v26.13.0 x64 and arm64, v26.12.0 x64). Two options: run the script once over SSH on a release VM, or, if we agree the check is worth keeping, create the nightly
notarize-darwin-tarballsjob described indoc/jenkins-jobs.md, whose first run is the backfill and which afterwards detects a tarball axis that stopped notarizing. The doc section can be dropped if we settle on the one-off run.Ref
nodewhen downloaded from the tarball #3538