2025-07-29, Version 24.5.0 (Current)

.github/workflows/lint-release-proposal.yml

@@ -39,7 +39,7 @@ jobs:
           EXPECTED_TRAILER="^$GITHUB_SERVER_URL/$GITHUB_REPOSITORY/pull/[[:digit:]]+\$"
           echo "Expected trailer format: $EXPECTED_TRAILER"
           PR_URL="$(git --no-pager log -1 --format='%(trailers:key=PR-URL,valueonly)')"
-          echo "Actual: $ACTUAL"
+          echo "Actual: $PR_URL"
           echo "$PR_URL" | grep -E -q "$EXPECTED_TRAILER"
 
           PR_HEAD="$(gh pr view "$PR_URL" --json headRefOid -q .headRefOid)"

CHANGELOG.md

@@ -40,7 +40,8 @@ release.
 </tr>
 <tr>
   <td valign="top">
-<b><a href="doc/changelogs/CHANGELOG_V24.md#24.4.1">24.4.1</a></b><br/>
+<b><a href="doc/changelogs/CHANGELOG_V24.md#24.5.0">24.5.0</a></b><br/>
+<a href="doc/changelogs/CHANGELOG_V24.md#24.4.1">24.4.1</a><br/>
 <a href="doc/changelogs/CHANGELOG_V24.md#24.4.0">24.4.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V24.md#24.3.0">24.3.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V24.md#24.2.0">24.2.0</a><br/>

LICENSE

@@ -2100,7 +2100,7 @@ The externally maintained libraries used by Node.js are:
 
 - inspector_protocol, located at deps/inspector_protocol, is licensed as follows:
   """
-    // Copyright 2016 The Chromium Authors. All rights reserved.
+    // Copyright 2016 The Chromium Authors.
     //
     // Redistribution and use in source and binary forms, with or without
     // modification, are permitted provided that the following conditions are

Makefile

@@ -1641,7 +1641,7 @@ HAS_DOCKER ?= $(shell command -v docker > /dev/null 2>&1; [ $$? -eq 0 ] && echo
 
 .PHONY: gen-openssl
 ifeq ($(HAS_DOCKER), 1)
-DOCKER_COMMAND ?= docker run -it -v $(PWD):/node
+DOCKER_COMMAND ?= docker run --rm -u $(shell id -u) -v $(PWD):/node
 IS_IN_WORKTREE = $(shell grep '^gitdir: ' $(PWD)/.git 2>/dev/null)
 GIT_WORKTREE_COMMON = $(shell git rev-parse --git-common-dir)
 DOCKER_COMMAND += $(if $(IS_IN_WORKTREE), -v $(GIT_WORKTREE_COMMON):$(GIT_WORKTREE_COMMON))

README.md

@@ -95,37 +95,27 @@ _docs_ subdirectory. Version-specific documentation is also at
 
 ### Verifying binaries
 
-Download directories contain a `SHASUMS256.txt` file with SHA checksums for the
-files.
+Download directories contain a `SHASUMS256.txt.asc` file with SHA checksums for the
+files and the releaser PGP signature.
 
-To download `SHASUMS256.txt` using `curl`:
+You can get a trusted keyring from nodejs/release-keys, e.g. using `curl`:
 
 ```bash
-curl -O https://nodejs.org/dist/vx.y.z/SHASUMS256.txt
+curl -fsLo "/path/to/nodejs-keyring.kbx" "https://github.com/nodejs/release-keys/raw/HEAD/gpg/pubring.kbx"
 ```
 
-To check that downloaded files match the checksum, use `sha256sum`:
+Alternatively, you can import the releaser keys in your default keyring, see
+[Release keys](#release-keys) for commands to how to do that.
 
-```bash
-sha256sum -c SHASUMS256.txt --ignore-missing
-```
-
-For Current and LTS, the GPG detached signature of `SHASUMS256.txt` is in
-`SHASUMS256.txt.sig`. You can use it with `gpg` to verify the integrity of
-`SHASUMS256.txt`. You will first need to import
-[the GPG keys of individuals authorized to create releases](#release-keys).
-
-See [Release keys](#release-keys) for commands to import active release keys.
-
-Next, download the `SHASUMS256.txt.sig` for the release:
+Then, you can verify the files you've downloaded locally
+(if you're using your default keyring, pass `--keyring="${GNUPGHOME:-~/.gnupg}/pubring.kbx"`):
 
 ```bash
-curl -O https://nodejs.org/dist/vx.y.z/SHASUMS256.txt.sig
+curl -fsO "https://nodejs.org/dist/${VERSION}/SHASUMS256.txt.asc" \
+&& gpgv --keyring="/path/to/nodejs-keyring.kbx" --output SHASUMS256.txt < SHASUMS256.txt.asc \
+&& shasum --check SHASUMS256.txt --ignore-missing
 ```
 
-Then use `gpg --verify SHASUMS256.txt.sig SHASUMS256.txt` to verify
-the file's signature.
-
 ## Building Node.js
 
 See [BUILDING.md](BUILDING.md) for instructions on how to build Node.js from
@@ -289,6 +279,8 @@ For information about the governance of the Node.js project, see
   **Abdirahim Musse** <<[email protected]>>
 * [addaleax](https://github.com/addaleax) -
   **Anna Henningsen** <<[email protected]>> (she/her)
+* [Aditi-1400](https://github.com/Aditi-1400) -
+  **Aditi Singh** <<[email protected]>> (she/her)
 * [aduh95](https://github.com/aduh95) -
   **Antoine du Hamel** <<[email protected]>> (he/him) - [Support me](https://github.com/sponsors/aduh95)
 * [anonrig](https://github.com/anonrig) -
@@ -383,8 +375,6 @@ For information about the governance of the Node.js project, see
   **Chengzhong Wu** <<[email protected]>> (he/him)
 * [lemire](https://github.com/lemire) -
   **Daniel Lemire** <<[email protected]>>
-* [Linkgoron](https://github.com/Linkgoron) -
-  **Nitzan Uziely** <<[email protected]>>
 * [LiviaMedeiros](https://github.com/LiviaMedeiros) -
   **LiviaMedeiros** <<[email protected]>>
 * [ljharb](https://github.com/ljharb) -
@@ -424,7 +414,7 @@ For information about the governance of the Node.js project, see
 * [Qard](https://github.com/Qard) -
   **Stephen Belanger** <<[email protected]>> (he/him)
 * [RafaelGSS](https://github.com/RafaelGSS) -
-  **Rafael Gonzaga** <<[email protected]>> (he/him)
+  **Rafael Gonzaga** <<[email protected]>> (he/him) - [Support me](https://github.com/sponsors/RafaelGSS)
 * [RaisinTen](https://github.com/RaisinTen) -
   **Darshan Sen** <<[email protected]>> (he/him) - [Support me](https://github.com/sponsors/RaisinTen)
 * [richardlau](https://github.com/richardlau) -
@@ -597,6 +587,8 @@ For information about the governance of the Node.js project, see
   **Lance Ball** <<[email protected]>> (he/him)
 * [Leko](https://github.com/Leko) -
   **Shingo Inoue** <<[email protected]>> (he/him)
+* [Linkgoron](https://github.com/Linkgoron) -
+  **Nitzan Uziely** <<[email protected]>>
 * [lucamaraschi](https://github.com/lucamaraschi) -
   **Luca Maraschi** <<[email protected]>> (he/him)
 * [lundibundi](https://github.com/lundibundi) -
@@ -790,7 +782,7 @@ responding to new issues.
 Primary GPG keys for Node.js Releasers (some Releasers sign with subkeys):
 
 * **Antoine du Hamel** <<[email protected]>>
-  `C0D6248439F1D5604AAFFB4021D900FFDB233756`
+  `5BE8A3F6C8A5C01D106C0AD820B1A390B168D356`
 * **Juan José Arboleda** <<[email protected]>>
   `DD792F5973C6DE52C432CBDAC77ABFA00DDBF2B7`
 * **Marco Ippolito** <<[email protected]>>
@@ -806,11 +798,14 @@ Primary GPG keys for Node.js Releasers (some Releasers sign with subkeys):
 * **Ulises Gascón** <<[email protected]>>
   `A363A499291CBBC940DD62E41F10027AF002F8B0`
 
-To import the full set of trusted release keys (including subkeys possibly used
-to sign releases):
+You can use the keyring the project maintains at
+<https://github.com/nodejs/release-keys/raw/refs/heads/main/gpg-only-active-keys/pubring.kbx>.
+Alternatively, you can import them from a public key server. Have in mind that
+the project cannot guarantee the availability of the server nor the keys on
+that server.
 
 ```bash
-gpg --keyserver hkps://keys.openpgp.org --recv-keys C0D6248439F1D5604AAFFB4021D900FFDB233756 # Antoine du Hamel
+gpg --keyserver hkps://keys.openpgp.org --recv-keys 5BE8A3F6C8A5C01D106C0AD820B1A390B168D356 # Antoine du Hamel
 gpg --keyserver hkps://keys.openpgp.org --recv-keys DD792F5973C6DE52C432CBDAC77ABFA00DDBF2B7 # Juan José Arboleda
 gpg --keyserver hkps://keys.openpgp.org --recv-keys CC68F5A3106FF448322E48ED27F5E38D5B0A215F # Marco Ippolito
 gpg --keyserver hkps://keys.openpgp.org --recv-keys 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 # Michaël Zasso
@@ -827,6 +822,8 @@ verify a downloaded file.
 
 <summary>Other keys used to sign some previous releases</summary>
 
+* **Antoine du Hamel** <<[email protected]>>
+  `C0D6248439F1D5604AAFFB4021D900FFDB233756`
 * **Beth Griggs** <<[email protected]>>
   `4ED778F539E3634C779C87C6D7062848A1AB005C`
 * **Bryan English** <<[email protected]>>
@@ -865,6 +862,9 @@ verify a downloaded file.
 * **Timothy J Fontaine** <<[email protected]>>
   `7937DFD2AB06298B2293C3187D33FF9D0246406D`
 
+The project maintains a keyring able to verify all past releases of Node.js at
+<https://github.com/nodejs/release-keys/raw/refs/heads/main/gpg/pubring.kbx>.
+
 </details>
 
 ### Security release stewards
@@ -880,6 +880,9 @@ releases on a rotation basis as outlined in the
 * [Datadog](https://www.datadoghq.com/)
   * [bengl](https://github.com/bengl) -
     **Bryan English** <<[email protected]>> (he/him)
+* [HeroDevs](https://www.herodevs.com/)
+  * [marco-ippolito](https://github.com/marco-ippolito) -
+    **Marco Ippolito** <<[email protected]>> (he/him)
 * [NodeSource](https://nodesource.com/)
   * [juanarbol](https://github.com/juanarbol) -
     **Juan José Arboleda** <<[email protected]>> (he/him)

SECURITY.md

@@ -109,6 +109,22 @@ does not trust is considered a vulnerability:
   the correct use of Node.js APIs.
 * The unavailability of the runtime, including the unbounded degradation of its
   performance.
+* Memory leaks qualify as vulnerabilities when all of the following criteria are met:
+  * The API is being correctly used.
+  * The API doesn't have a warning against its usage in a production environment.
+  * The API is public and documented.
+  * The API is on stable (2.0) status.
+  * The memory leak is significant enough to cause a denial of service quickly
+    or in a context not controlled by the user (for example, HTTP parsing).
+  * The memory leak is directly exploitable by an untrusted source without requiring application mistakes.
+  * The leak cannot be reasonably mitigated through standard operational practices (like process recycling).
+  * The leak occurs deterministically under normal usage patterns rather than edge cases.
+  * The leak occurs at a rate that would cause practical resource exhaustion within a practical timeframe under
+    typical workloads.
+  * The attack demonstrates [asymmetric resource consumption](https://cwe.mitre.org/data/definitions/405.html),
+    where the attacker expends significantly fewer resources than what's required by the server to process the
+    attack. Attacks requiring comparable resources on the attacker's side (which can be mitigated through common
+    practices like rate limiting) may not qualify.
 
 If Node.js loads configuration files or runs code by default (without a
 specific request from the user), and this is not documented, it is considered a
@@ -125,7 +141,7 @@ Vulnerabilities related to this case may be fixed by a documentation update.
 * The data received from the remote end of outbound network connections
   that are created through the use of Node.js APIs and
   which is transformed/validated by Node.js before being passed
-  to the application EXCEPT with respect to payload length. Node.js trusts
+  to the application **except** with respect to payload length. Node.js trusts
   that applications make connections/requests which will avoid payload
   sizes that will result in a Denial of Service.
   * HTTP APIs (all flavors) client APIs.
@@ -146,9 +162,9 @@ then untrusted input must not lead to arbitrary JavaScript code execution.
 
 **Node.js trusts everything else**. Examples include:
 
-* The developers and infrastructure that runs it.
+* The developers and infrastructure that run it.
 * The operating system that Node.js is running under and its configuration,
-  along with anything under control of the operating system.
+  along with anything under the control of the operating system.
 * The code it is asked to run, including JavaScript, WASM and native code, even
   if said code is dynamically loaded, e.g., all dependencies installed from the
   npm registry.
@@ -184,12 +200,12 @@ the community they pose.
 
 * Node.js provides APIs to validate handling of Subject Alternative Names (SANs)
   in certificates used to connect to a TLS/SSL endpoint. If certificates can be
-  crafted which result in incorrect validation by the Node.js APIs that is
+  crafted that result in incorrect validation by the Node.js APIs that is
   considered a vulnerability.
 
 #### Inconsistent Interpretation of HTTP Requests (CWE-444)
 
-* Node.js provides APIs to accept http connections. Those APIs parse the
+* Node.js provides APIs to accept HTTP connections. Those APIs parse the
   headers received for a connection and pass them on to the application.
   Bugs in parsing those headers which can result in request smuggling are
   considered vulnerabilities.
@@ -202,9 +218,9 @@ the community they pose.
 
 #### External Control of System or Configuration Setting (CWE-15)
 
-* If Node.js automatically loads a configuration file which is not documented
+* If Node.js automatically loads a configuration file that is not documented
   and modification of that configuration can affect the confidentiality of
-  data protected using the Node.js APIs this is considered a vulnerability.
+  data protected using the Node.js APIs, then this is considered a vulnerability.
 
 ### Examples of non-vulnerabilities
 
@@ -227,7 +243,7 @@ the community they pose.
 
 #### External Control of System or Configuration Setting (CWE-15)
 
-* If Node.js automatically loads a configuration file which is documented
+* If Node.js automatically loads a configuration file that is documented,
   no scenario that requires modification of that configuration file is
   considered a vulnerability.
 
@@ -247,9 +263,9 @@ the community they pose.
 
 ## Assessing experimental features reports
 
-Experimental features are eligible to reports as any other stable feature of
-Node.js. They will also be susceptible to receiving the same severity score
-as any other stable feature.
+Experimental features are eligible for security reports just like any other
+stable feature of Node.js. They may also receive the same severity score that a
+stable feature would.
 
 ## Receiving security updates
 

benchmark/_cli.js

@@ -140,8 +140,8 @@ CLI.prototype.getCpuCoreSetting = function() {
   const isValid = /^(\d+(-\d+)?)(,\d+(-\d+)?)*$/.test(value);
   if (!isValid) {
     throw new Error(`
-        Invalid CPUSET format: "${value}". Please use a single core number (e.g., "0"), 
-        a range of cores (e.g., "0-3"), or a list of cores/ranges 
+        Invalid CPUSET format: "${value}". Please use a single core number (e.g., "0"),
+        a range of cores (e.g., "0-3"), or a list of cores/ranges
         (e.g., "0,2,4" or "0-2,4").\n\n${this.usage}
     `);
   }

benchmark/common.js

@@ -386,7 +386,7 @@ function getUrlData(withBase) {
  * @param {number} e The repetition of the data, as exponent of 2
  * @param {boolean} withBase Whether to include a base URL
  * @param {boolean} asUrl Whether to return the results as URL objects
- * @return {string[] | string[][] | URL[]}
+ * @returns {string[] | string[][] | URL[]}
  */
 function bakeUrlData(type, e = 0, withBase = false, asUrl = false) {
   let result = [];

benchmark/diagnostics_channel/subscribe.js

@@ -3,17 +3,16 @@ const common = require('../common.js');
 const dc = require('diagnostics_channel');
 
 const bench = common.createBenchmark(main, {
-  n: [1e8],
+  n: [1e5],
 });
 
-function noop() {}
+function noop() { }
 
 function main({ n }) {
-  const channel = dc.channel('channel.0');
 
   bench.start();
   for (let i = 0; i < n; i++) {
-    channel.subscribe(noop);
+    dc.subscribe('channel.0', noop);
   }
   bench.end(n);
 }