Repository navigation
Request official build records for Node.js v24.19.0 win-x64/node.exe #4524
Description
Hello Build WG,
Could you point to publicly shareable official build records and effective build configuration for the following release artifact?
- Node.js version: v24.19.0, Windows x64,
win-x64/node.exe. - Official published SHA-256:
3602f2bb1a10f2cbab4c36886218a33c1ab3db87290e73b033c46c77147d0237. - Official checksum list: https://nodejs.org/download/release/v24.19.0/SHASUMS256.txt
- Release-build references:
iojs+release/11987→iojs+release/11989:
Those build numbers are references to investigate, not an assertion that a particular Windows worker produced the final published artifact.
The missing records requested are:
- The exact Windows x64 worker job/run and source commit actually used for this artifact.
- The effective configuration, compiler definitions/overrides and dependency selections for that build (
config.gypi, configure arguments, Windows project/compiler settings, or equivalent official records). In particular:EXPERIMENTALS_DEFAULT_VALUE, including the effectivenode_enable_experimentalssetting and any overrides.- Whether
DEBUGwas defined or undefined. - Whether
NODE_OPENSSL_DEFAULT_CIPHER_LISTwas overridden and, if so, its effective value. - The QUIC adapter/dependency selection and effective
QUIC_NGTCP2_USE_OPENSSL_3_5/OPENSSL_NO_QUICdefinitions.
- The association between that build's output and the final published SHA-256 above, including any signing/publication steps that changed artifact bytes.
Public links or a non-sensitive, redacted export would be sufficient. No credentials, CI access grants, new builds or test reruns are requested. If some records were not retained or cannot be shared, please indicate which parts remain unavailable; generic build recipes or source defaults alone would not establish the effective configuration of this exact artifact.
Thank you.
Activity
sxa commentedon Oct 19, 2026
As per the answer I gave to someone else recently in #4513 (comment) we do not actively store that information for our builds at this time, however none of the values you have mentioned should have been overridden from the defaults.
The source commit would have been the one tagged with the name of the release e.g. https://github.com/nodejs/node/tree/v24.19.0 (commit
cdc1b38d40cb567b7ad0b39c86addf830a0af0ae)XQY1212 commentedon Oct 25, 2026
Follow-up: retained build, snapshot and publication links for v24.19.0 Windows x64
Hello Node.js Build Working Group,
Thank you for explaining in this issue that the requested per-build information is not actively stored, and for pointing to the release-tag source commit. Could any separately retained records or a source-attributed maintainer explanation establish the following remaining links? We are not repeating the earlier compiler-settings request or asking for missing records to be recreated.
The artifact is:
v24.19.0/win-x64/node.exe3602f2bb1a10f2cbab4c36886218a33c1ab3db87290e73b033c46c77147d0237cdc1b38d40cb567b7ad0b39c86addf830a0af0aeiojs+release/11987and11989, referenced in the release PR comment. We do not assume that 11989 supplied the published binary.1. Release jobs → actual Windows build → final binary
Is there a retained summary showing the relationship between 11987 and 11989, which attempt was selected or superseded, and the actual Windows x64 child job? Useful identifiers would be its URL or ID, a non-sensitive logical worker identifier, source commit, result and timestamps, plus the archived artifact path and digest. If rebuilding, signing or repackaging changed the bytes, any existing input-to-output digest mapping to the published SHA-256 would help.
2. Actual build → snapshot generation → inclusion in the binary
Is there a record tied to that build of the effective snapshot, code-cache and custom-entry options or overrides; the actual
node_mksnapshotaction and inputs; and the identity or digest of generatednode_snapshot.ccand its inclusion in the final binary? An equivalent association is welcome. If snapshot generation was disabled or another branch was used, please identify the available basis for that. We do not require particular filenames or an external blob for an embedded snapshot.3. Build archive → staging → published artifact
Are there retained promotion or equivalent publication records connecting the source job or archived object to the destination, transfer time and final SHA-256? The historical tool revision or equivalent workflow description would help if retained. If a log lacks job identifiers or digests, an associated archive manifest or source-attributed explanation may bridge the link. We are not assuming which promotion tools were used.
Public official links, sanitized existing extracts or an explanation identifying its basis are all welcome. Please exclude credentials, tokens, full environment-variable values and unrelated host details. If a link cannot be established, identifying the unavailable records and any known retention policy, backup or equivalent evidence is sufficient. We are not requesting CI access, a new build, or a new signing, reproducibility or full-toolchain audit.
Thank you for helping distinguish what can be established from what remains unknown.
sxa commentedon Oct 26, 2026
If anyone else from @nodejs/releasers wishes to look into this they can comment be we do not typically retain that sort of information and we would not have any specific records that would demonstrate the thing you're looking for in given that this is a release from nearly three months ago. I would also make it clear at this point that there has been an important security release in the last week and I would urge you not to continue to use 24.19.0 and use the latest version.