Add zlib.crc32c(data[, value]), which computes the CRC-32C checksum
(Castagnoli polynomial, RFC 3720 section 12.1). CRC-32C has better
error detection properties than the CRC-32 of zlib.crc32() and is the
checksum required by many current protocols, formats and services,
among them:
- iSCSI header and data digests (RFC 7143)
- SCTP packet checksums (RFC 9260)
- iWARP MPA framing (RFC 5044)
- NVMe/TCP header and data digests
- ext4, Btrfs and XFS metadata checksums
- the Snappy framing format
- Apache Kafka record batches
- LevelDB and RocksDB block checksums
- TensorFlow TFRecord files
- Google Cloud Storage and Amazon S3 object checksums
Implementing any of these in JavaScript currently needs a userland
CRC-32C, which is far slower than native code.
The function mirrors zlib.crc32(): it accepts a string (encoded as
UTF-8) or an ArrayBufferView, takes an optional 32-bit unsigned
starting value so a checksum can be continued across chunks, and has a
V8 fast API path.
The checksum is computed by absl::ExtendCrc32c() from the bundled
Abseil, which is already built and linked into node, so this adds no
new dependency and no new checksum implementation. absl_crc32c is
added to the libraries linked with --shared-abseil.
Abseil selects its hardware-accelerated CRC-32C path (SSE4.2 and
PCLMULQDQ on x64, the CRC32 and PMULL extensions on arm64) at compile
time, so with node's default compiler flags the portable table-driven
implementation is used. It runs at about the same speed as zlib.crc32()
(about 6.5 GB/s on a recent x64 machine), while the hardware path
reaches about 38 GB/s. Builds whose target CPU baseline already
includes those instructions get the hardware path without changes.
Enabling it for generic builds is left out on purpose: on x64, Abseil
uses the accelerated code for unrecognized CPUs without a runtime
feature check, so compiling it in unconditionally would fault on CPUs
without SSE4.2.
Signed-off-by: Philipp Dunkel <pip@pipobscure.com>
PR-URL: https://github.com/nodejs/node/pull/66828
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
V8 defaults `v8_enable_sandbox` to on whenever the shared pointer
compression cage and the external code space are enabled, and that is
the configuration embedders that use the sandbox build with. Now that
the sandbox builds and passes the tests, follow that default for
`--experimental-pointer-compression-shared-cage` so the configuration
is reachable from `configure`. Multi-cage pointer compression builds
stay without it: there every IsolateGroup gets its own sandbox, and
`NodeArrayBufferAllocator` always allocates from the default one.
Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/62237
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
A missing OPENSSL_VERSION_NUMBER macro raises TypeError while the
configure logic attempts to slice None. Treat that like the other
version detection failures so configure warns and records version 0.
Signed-off-by: Filip Skokan <panva.ip@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/64982
Reviewed-By: Richard Lau <richard.lau@ibm.com>
Reviewed-By: Aviv Keller <me@aviv.sh>
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>
V8's Maglev compiler has supported riscv64 since V8 14.0 (with full
source files in deps/v8/src/maglev/riscv/), but Node.js never wired
it up:
- configure.py excluded riscv64 from maglev_enabled_architectures
- tools/v8_gypfiles/v8.gyp lacked GN-scraper conditions for riscv64
Maglev sources in both the v8_internal_headers and
v8_base_without_compiler blocks
This adds riscv64 to both, following the same pattern used for s390x
in #60863 and matching V8's own BUILD.gn which already lists riscv64
alongside arm, arm64, x64, s390x, and ppc64 as Maglev-enabled
architectures.
Refs: https://github.com/nodejs/build/issues/4099
Signed-off-by: Jamie Magee <jamie.magee@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/62605
Reviewed-By: René <contact.9a5d6388@renegade334.me.uk>
Reviewed-By: Stewart X Addison <sxa@redhat.com>
Reviewed-By: Richard Lau <richard.lau@ibm.com>
Decided to take a short break from the work on QUIC
to implement a DTLS API. Very experimental at this
point but the basic API is there (inspired by the
QUIC API work).
The implementation is based on OpenSSL's built-in
DTLS support and no other dependencies are required.
DTLS is a datagram-based version of TLS that is used
for things like WebRTC and CoAP. It provides similar
security guarantees as TLS but is designed to work over
UDP instead of TCP.
This shouldn't be considered ready for production
but it is a good starting point for experimentation
and feedback.
```bash
./configure --experimental-dtls
make -j{nproc}
./node --experimental-dtls my-dtls-app.js
```
Signed-off-by: James M Snell <jasnell@gmail.com>
Assisted-by: Opencode:Opus 4.6
PR-URL: https://github.com/nodejs/node/pull/63182
Fixes: https://github.com/nodejs/node/issues/61630
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
When we build the macOS pkg, we build Node.js twice (on arm64):
- Once for arm64 (native)
- Once for x64, using a combination of Rosetta 2 and compiler flags
before combining both into a universal binary.
For the x64 case, pass target flag to `rustc` so that the binary is
built for the correct target architecture.
Signed-off-by: Richard Lau <richard.lau@ibm.com>
PR-URL: https://github.com/nodejs/node/pull/63015
Reviewed-By: Stewart X Addison <sxa@redhat.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Enabling Temporal support requires `cargo` and `rustc`, which are new
build toolchain requirements.
Add a `--v8-disable-temporal-support` option to `configure.py` to
explicitly opt-out of Temporal support (i.e. no need for Rust).
If the existing `--v8-enable-temporal-support` option is not explicitly
passed to `configure.py`:
- Attempt to detect `cargo` and `rustc`.
- If neither `cargo` and `rustc` are detected, print a warning and
disable Temporal support.
- If both `cargo` and `rustc` are detected, enable Temporal support.
If `--v8-enable-temporal-support` is passed to `configure.py`, then
the build will error and stop if `cargo` and/or `rustc` are not
detected.
To avoid ambiguity, `configure.py` will error and stop if both
`--v8-disable-temporal-support` and `--v8-enable-temporal-support` are
used.
Signed-off-by: Richard Lau <richard.lau@ibm.com>
PR-URL: https://github.com/nodejs/node/pull/61806
Fixes: https://github.com/nodejs/node/issues/57127
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Aviv Keller <me@aviv.sh>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
When enabling support for Temporal, check for the `CARGO` environment
variable to locate the `cargo` binary (defaulting to `cargo` if not
set) and use this to build `deps/crates`.
This will allow using Cargo on systems where the Cargo binary name is
suffixed with the version, e.g. `cargo-1.82` on Ubuntu 24.04.
PR-URL: https://github.com/nodejs/node/pull/62421
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Filip Skokan