This separates the native crypto backend paths for OpenSSL >= 3,
BoringSSL, and legacy OpenSSL. The OpenSSL >= 3 path now builds with
`OPENSSL_API_COMPAT=30000` and `OPENSSL_NO_DEPRECATED`, moving normal
crypto/TLS code away from APIs that OpenSSL 3.0.0 marks deprecated.
BoringSSL remains on its own branch, and OpenSSL < 3 remains the legacy
fallback.
The exception is ENGINE support. ENGINE APIs are isolated into a
dedicated compatibility target so they can remain available while the
JS-facing engine APIs are runtime-deprecated in 27.x. That gives us a
clear removal point for 28.x, without letting ENGINE usage leak back
into the strict OpenSSL 3 path.
The split also makes the eventual OpenSSL 1.1.1 removal easier to reason
about. Once support for OpenSSL < 3 is dropped, the legacy branch can be
removed in a focused follow-up, possibly targeting 27.x, instead of
untangling mixed version guards throughout the crypto implementation.
No public crypto or TLS API behavior is intentionally changed.
Assisted-by: Codex:gpt-5
Signed-off-by: Filip Skokan <panva.ip@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/64211
Refs: https://github.com/nodejs/node/issues/56733
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Richard Lau <richard.lau@ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Add v8::ArrayBuffer::CopyArrayBufferBytes and
v8::SharedArrayBuffer::CopyArrayBufferBytes, which copy a byte range
from one backing store to another. V8 clamps the byte range and handles
detached and immutable buffers: nothing is copied when the source is
detached or the target is detached or immutable, and the number of bytes
actually copied is returned. The SharedArrayBuffer overload uses a
relaxed-atomic memmove that honors the SharedArrayBuffer memory model.
Carried as a floating patch cherry-picked from:
https://chromium-review.googlesource.com/c/v8/v8/+/7735151
That CL is authored by a Node.js collaborator (Ben Noordhuis) and is
expected to land upstream, so the floating patch should be easy to
maintain: it touches nothing but the public ArrayBuffer API and can be
dropped wholesale on the next V8 upgrade that includes it.
v8_embedder_string is bumped to -node.21 accordingly.
Refs: https://chromium-review.googlesource.com/c/v8/v8/+/7735151
Signed-off-by: Robert Nagy <ronagy@icloud.com>
PR-URL: https://github.com/nodejs/node/pull/63828
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: René <contact.9a5d6388@renegade334.me.uk>
This enables v8_enable_seeded_array_index_hash and add a test for it.
deps: V8: backport 0a8b1cdcc8b2
Original commit message:
implement rapidhash secret generation
Bug: 409717082
Change-Id: I471f33d66de32002f744aeba534c1d34f71e27d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6733490
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: snek <snek@chromium.org>
Cr-Commit-Position: refs/heads/main@{#101499}
deps: V8: backport 185f0fe09b72
Original commit message:
[numbers] Refactor HashSeed as a lightweight view over ByteArray
Instead of copying the seed and secrets into a struct with value
fields, HashSeed now stores a pointer pointing either into the
read-only ByteArray, or the static default seed for off-heap
HashSeed::Default() calls. The underlying storage is always
8-byte aligned so we can cast it directly into a struct.
Change-Id: I5896a7f2ae24296eb4c80b757a5d90ac70a34866
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7609720
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#105531}
deps: V8: backport 1361b2a49d02
Original commit message:
[strings] improve array index hash distribution
Previously, the hashes stored in a Name's raw_hash_field for decimal
numeric strings (potential array indices) consist of the literal
integer value along with the length of the string. This means
consecutive numeric strings can have consecutive hash values, which
can lead to O(n^2) probing for insertion in the worst case when e.g.
a non-numeric string happen to land in the these buckets.
This patch adds a build-time flag v8_enable_seeded_array_index_hash
that scrambles the 24-bit array-index value stored in a Name's
raw_hash_field to improve the distribution.
x ^= x >> kShift; x = (x * m1) & kMask; // round 1
x ^= x >> kShift; x = (x * m2) & kMask; // round 2
x ^= x >> kShift; // finalize
To decode, apply the same steps with the modular inverses of m1
and m2 in reverse order.
x ^= x >> kShift; x = (x * m2_inv) & kMask; // round 1
x ^= x >> kShift; x = (x * m1_inv) & kMask; // round 2
x ^= x >> kShift; // finalize
where kShift = kArrayIndexValueBits / 2, kMask = kArrayIndexValueMask,
m1, m2 (both odd) are the lower bits of the rapidhash secrets, m1_inv,
m2_inv (modular inverses) are precomputed modular inverse of m1 and m2.
The pre-computed values are appended to the hash_seed ByteArray in
ReadOnlyRoots and accessed in generated code to reduce overhead.
In call sites that don't already have access to the seeds, we read them
from the current isolate group/isolate's read only roots.
To consolidate the code that encode/decode these hashes, this patch
adds MakeArrayIndexHash/DecodeArrayIndexFromHashField in C++ and CSA
that perform seeding/unseeding if enabled, and updates places where
encoding/decoding of array index is needed to use them.
Bug: 477515021
Change-Id: I350afe511951a54c4378396538152cc56565fd55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7564330
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#105596}
deps: V8: cherry-pick aac14dd95e5b
Original commit message:
[string] add 3rd round to seeded array index hash
Since we already have 3 derived secrets, and arithmetics are
relatively cheap, add a 3rd round to the xorshift-multiply
seeding scheme. This brings the bias from ~3.4 to ~0.4.
Bug: 477515021
Change-Id: I1ef48954bcee8768d8c90db06ac8adb02f06cebf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7655117
Reviewed-by: Chengzhong Wu <cwu631@bloomberg.net>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#105824}
PR-URL: https://github.com/nodejs-private/node-private/pull/834
CVE-ID: CVE-2026-21717
deps: V8: backport 185f0fe09b72
Original commit message:
[numbers] Refactor HashSeed as a lightweight view over ByteArray
Instead of copying the seed and secrets into a struct with value
fields, HashSeed now stores a pointer pointing either into the
read-only ByteArray, or the static default seed for off-heap
HashSeed::Default() calls. The underlying storage is always
8-byte aligned so we can cast it directly into a struct.
Change-Id: I5896a7f2ae24296eb4c80b757a5d90ac70a34866
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7609720
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#105531}
deps: V8: backport 1361b2a49d02
Original commit message:
[strings] improve array index hash distribution
Previously, the hashes stored in a Name's raw_hash_field for decimal
numeric strings (potential array indices) consist of the literal
integer value along with the length of the string. This means
consecutive numeric strings can have consecutive hash values, which
can lead to O(n^2) probing for insertion in the worst case when e.g.
a non-numeric string happen to land in the these buckets.
This patch adds a build-time flag v8_enable_seeded_array_index_hash that
scrambles the 24-bit array-index value stored in a Name's raw_hash_field
to improve the distribution.
x ^= x >> kShift; x = (x * m1) & kMask; // round 1
x ^= x >> kShift; x = (x * m2) & kMask; // round 2
x ^= x >> kShift; // finalize
To decode, apply the same steps with the modular inverses of m1 and m2
in reverse order.
x ^= x >> kShift; x = (x * m2_inv) & kMask; // round 1
x ^= x >> kShift; x = (x * m1_inv) & kMask; // round 2
x ^= x >> kShift; // finalize
where kShift = kArrayIndexValueBits / 2, kMask = kArrayIndexValueMask,
m1, m2 (both odd) are the lower bits of the rapidhash secrets, m1_inv,
m2_inv (modular inverses) are precomputed modular inverse of m1 and m2.
The pre-computed values are appended to the hash_seed ByteArray in
ReadOnlyRoots and accessed in generated code to reduce overhead.
In call sites that don't already have access to the seeds, we read them
from the current isolate group/isolate's read only roots.
To consolidate the code that encode/decode these hashes, this patch
adds MakeArrayIndexHash/DecodeArrayIndexFromHashField in C++ and CSA
that perform seeding/unseeding if enabled, and updates places where
encoding/decoding of array index is needed to use them.
Bug: 477515021
Change-Id: I350afe511951a54c4378396538152cc56565fd55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7564330
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#105596}
deps: V8: cherry-pick aac14dd95e5b
Original commit message:
[string] add 3rd round to seeded array index hash
Since we already have 3 derived secrets, and arithmetics are
relatively cheap, add a 3rd round to the xorshift-multiply
seeding scheme. This brings the bias from ~3.4 to ~0.4.
Bug: 477515021
Change-Id: I1ef48954bcee8768d8c90db06ac8adb02f06cebf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7655117
Reviewed-by: Chengzhong Wu <cwu631@bloomberg.net>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#105824}
Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com>
Refs: https://hackerone.com/reports/3511792
Refs: https://github.com/v8/v8/commit/aac14dd95e5be0d487eba6bcdaf9cef4f8bd806c
PR-URL: https://github.com/nodejs/node/pull/61898
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
The `-fuse-linker-plugin` flag has been automatically enabled by GCC
since version 5 when LTO is active, making the explicit flag
redundant. Since Node.js requires GCC >= 13.2, this flag serves no
purpose.
Removing it also improves portability with alternative linkers (mold,
lld) that may not support GCC's linker plugin interface, avoiding
build failures when these linkers are used with GCC LTO builds.
Refs: https://github.com/yao-pkg/pkg/issues/231
Signed-off-by: Daniel Lando <daniel.sorridi@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/62667
Reviewed-By: Richard Lau <richard.lau@ibm.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
This enables v8_enable_seeded_array_index_hash and add a test for it.
Fixes: https://hackerone.com/reports/3511792
deps: V8: backport 0a8b1cdcc8b2
Original commit message:
implement rapidhash secret generation
Bug: 409717082
Change-Id: I471f33d66de32002f744aeba534c1d34f71e27d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6733490
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: snek <snek@chromium.org>
Cr-Commit-Position: refs/heads/main@{#101499}
Refs: https://github.com/v8/v8/commit/0a8b1cdcc8b243c62cf045fa8beb50600e11758a
Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com>
deps: V8: backport 185f0fe09b72
Original commit message:
[numbers] Refactor HashSeed as a lightweight view over ByteArray
Instead of copying the seed and secrets into a struct with value
fields, HashSeed now stores a pointer pointing either into the
read-only ByteArray, or the static default seed for off-heap
HashSeed::Default() calls. The underlying storage is always
8-byte aligned so we can cast it directly into a struct.
Change-Id: I5896a7f2ae24296eb4c80b757a5d90ac70a34866
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7609720
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#105531}
Refs: https://github.com/v8/v8/commit/185f0fe09b72fb869fdcf9a89f40ff2295436bca
Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com>
deps: V8: backport 1361b2a49d02
Original commit message:
[strings] improve array index hash distribution
Previously, the hashes stored in a Name's raw_hash_field for decimal
numeric strings (potential array indices) consist of the literal
integer value along with the length of the string. This means
consecutive numeric strings can have consecutive hash values, which
can lead to O(n^2) probing for insertion in the worst case when e.g.
a non-numeric string happen to land in the these buckets.
This patch adds a build-time flag v8_enable_seeded_array_index_hash that
scrambles the 24-bit array-index value stored in a Name's raw_hash_field
to improve the distribution.
x ^= x >> kShift; x = (x * m1) & kMask; // round 1
x ^= x >> kShift; x = (x * m2) & kMask; // round 2
x ^= x >> kShift; // finalize
To decode, apply the same steps with the modular inverses of m1 and m2
in reverse order.
x ^= x >> kShift; x = (x * m2_inv) & kMask; // round 1
x ^= x >> kShift; x = (x * m1_inv) & kMask; // round 2
x ^= x >> kShift; // finalize
where kShift = kArrayIndexValueBits / 2, kMask = kArrayIndexValueMask,
m1, m2 (both odd) are the lower bits of the rapidhash secrets, m1_inv,
m2_inv (modular inverses) are precomputed modular inverse of m1 and m2.
The pre-computed values are appended to the hash_seed ByteArray in
ReadOnlyRoots and accessed in generated code to reduce overhead.
In call sites that don't already have access to the seeds, we read them
from the current isolate group/isolate's read only roots.
To consolidate the code that encode/decode these hashes, this patch
adds MakeArrayIndexHash/DecodeArrayIndexFromHashField in C++ and CSA
that perform seeding/unseeding if enabled, and updates places where
encoding/decoding of array index is needed to use them.
Bug: 477515021
Change-Id: I350afe511951a54c4378396538152cc56565fd55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7564330
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#105596}
Refs: https://github.com/v8/v8/commit/1361b2a49d020a718dc5495713eae0fa67d697b9
Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com>
deps: V8: cherry-pick aac14dd95e5b
Original commit message:
[string] add 3rd round to seeded array index hash
Since we already have 3 derived secrets, and arithmetics are
relatively cheap, add a 3rd round to the xorshift-multiply
seeding scheme. This brings the bias from ~3.4 to ~0.4.
Bug: 477515021
Change-Id: I1ef48954bcee8768d8c90db06ac8adb02f06cebf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7655117
Reviewed-by: Chengzhong Wu <cwu631@bloomberg.net>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#105824}
Refs: https://github.com/v8/v8/commit/aac14dd95e5be0d487eba6bcdaf9cef4f8bd806c
PR-URL: https://github.com/nodejs-private/node-private/pull/834
CVE-ID: CVE-2026-21717
deps: V8: backport 185f0fe09b72
Original commit message:
[numbers] Refactor HashSeed as a lightweight view over ByteArray
Instead of copying the seed and secrets into a struct with value
fields, HashSeed now stores a pointer pointing either into the
read-only ByteArray, or the static default seed for off-heap
HashSeed::Default() calls. The underlying storage is always
8-byte aligned so we can cast it directly into a struct.
Change-Id: I5896a7f2ae24296eb4c80b757a5d90ac70a34866
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7609720
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#105531}
Refs: https://github.com/v8/v8/commit/185f0fe09b72fb869fdcf9a89f40ff2295436bca
Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com>
deps: V8: backport 1361b2a49d02
Original commit message:
[strings] improve array index hash distribution
Previously, the hashes stored in a Name's raw_hash_field for decimal
numeric strings (potential array indices) consist of the literal
integer value along with the length of the string. This means
consecutive numeric strings can have consecutive hash values, which
can lead to O(n^2) probing for insertion in the worst case when e.g.
a non-numeric string happen to land in the these buckets.
This patch adds a build-time flag v8_enable_seeded_array_index_hash that
scrambles the 24-bit array-index value stored in a Name's raw_hash_field
to improve the distribution.
x ^= x >> kShift; x = (x * m1) & kMask; // round 1
x ^= x >> kShift; x = (x * m2) & kMask; // round 2
x ^= x >> kShift; // finalize
To decode, apply the same steps with the modular inverses of m1 and m2
in reverse order.
x ^= x >> kShift; x = (x * m2_inv) & kMask; // round 1
x ^= x >> kShift; x = (x * m1_inv) & kMask; // round 2
x ^= x >> kShift; // finalize
where kShift = kArrayIndexValueBits / 2, kMask = kArrayIndexValueMask,
m1, m2 (both odd) are the lower bits of the rapidhash secrets, m1_inv,
m2_inv (modular inverses) are precomputed modular inverse of m1 and m2.
The pre-computed values are appended to the hash_seed ByteArray in
ReadOnlyRoots and accessed in generated code to reduce overhead.
In call sites that don't already have access to the seeds, we read them
from the current isolate group/isolate's read only roots.
To consolidate the code that encode/decode these hashes, this patch
adds MakeArrayIndexHash/DecodeArrayIndexFromHashField in C++ and CSA
that perform seeding/unseeding if enabled, and updates places where
encoding/decoding of array index is needed to use them.
Bug: 477515021
Change-Id: I350afe511951a54c4378396538152cc56565fd55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7564330
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#105596}
Refs: https://github.com/v8/v8/commit/1361b2a49d020a718dc5495713eae0fa67d697b9
Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com>
deps: V8: cherry-pick aac14dd95e5b
Original commit message:
[string] add 3rd round to seeded array index hash
Since we already have 3 derived secrets, and arithmetics are
relatively cheap, add a 3rd round to the xorshift-multiply
seeding scheme. This brings the bias from ~3.4 to ~0.4.
Bug: 477515021
Change-Id: I1ef48954bcee8768d8c90db06ac8adb02f06cebf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7655117
Reviewed-by: Chengzhong Wu <cwu631@bloomberg.net>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#105824}
Refs: https://github.com/v8/v8/commit/aac14dd95e5be0d487eba6bcdaf9cef4f8bd806c
Original commit message:
Fix gcc build
For json-parser.h:
```
../../src/json/json-parser.h:298:13: error: explicit specialization in
non-namespace scope 'class v8::internal::JsonParser<Char>'
298 | template <>
| ^
../../src/json/json-parser.h:299:18: error: template-id
'IsNextToken<v8::internal::JsonToken::EOS>' in declaration of primary template
299 | V8_INLINE bool IsNextToken<JsonToken::EOS>() {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
```
For wasm-objects.cc:
```
../../src/wasm/wasm-objects.cc:2522:45: error: no matching function for call to
'v8::internal::WasmDispatchTable::SetForNonWrapper<v8::internal::WasmDispatchTable>(
v8::internal::WasmDispatchTable&, int&, v8::internal::Tagged<v8::internal::
Union<v8::internal::Smi, v8::internal::WasmTrustedInstanceData> >&,
v8::internal::WasmCodePointer&, v8::internal::wasm::CanonicalTypeIndex&,
v8::internal::WasmDispatchTable::NewOrExistingEntry&)'
```
```
error: no matching function for call to 'v8::internal::WasmDispatchTable::
SetForWrapper<v8::internal::WasmDispatchTable>(v8::internal::WasmDispatchTable&,
int&, v8::internal::Tagged<v8::internal::WasmImportData>&, std::shared_ptr<v8::
internal::wasm::WasmImportWrapperHandle>&, v8::internal::wasm::
CanonicalTypeIndex&, v8::internal::WasmDispatchTable::NewOrExistingEntry&)'
```
For the fix fully qualify calls to SetForWrapper and SetForNonWrapper with
::v8::internal:: to avoid accidental lookup of class member names.
This resolves template resolution errors caused by unqualified
calls inside WasmDispatchTable and WasmDispatchTableForImports
member functions.
Change-Id: I687935a05dc754db686deaa0f93079d350aae07e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7107891
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@ibm.com>
Cr-Commit-Position: refs/heads/main@{#103547}
Refs: https://github.com/v8/v8/commit/151d0a44a1b2fa5dcdc1282101f71916f303aae6
Co-authored-by: Michaël Zasso <targos@protonmail.com>
PR-URL: https://github.com/nodejs/node/pull/60488
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Richard Lau <richard.lau@ibm.com>
avivkeller