Chris Tate
4eac513f61
On x86-64 CPUs that support them, createCipheriv and createDecipheriv use new kernels in scr_cipher_simd.c instead of the mbedTLS implementations: AES-CTR encrypts eight blocks per step with AES-NI; AES-GCM encrypts eight blocks per step while folding the previous step's ciphertext into GHASH with PCLMULQDQ, or sixteen blocks per step with VAES and VPCLMULQDQ; CBC decryption runs eight blocks per step, ChaCha20 runs eight blocks per step with AVX2 or sixteen with AVX-512F, and Poly1305 processes eight blocks per step with AVX-512 IFMA or four with 64-bit scalar arithmetic. CPU support is checked with CPUID and XCR0 when a cipher is created; other CPUs and architectures keep the mbedTLS path. The GCM kernel enforces the same message and AAD limits as mbedTLS, so a failed update retires the context on either path. A runtime C test (cipher-kernels.test.ts) checks both paths against 500 Node-generated cases with several chunkings (and the eight-block GCM loop on VAES hosts), cipher.test.ts checks the GCM limits through the kernels, and new corpus programs cover bulk data, counter carries, non-12-byte GCM IVs, chacha20-poly1305 batches and tampered inputs.
Node compatibility ledger
This workspace package owns scriptc's Node.js parity system.
node-v24.jsonpins the Node release tag, commit, and canonical docs/source inputs.static-support.jsonoverlays dedicated compiler paths and their internal test evidence on the compiler's generated surface manifest.generated/node-v24-internal.jsonis the engineering ledger, including implementation evidence and repository test paths.generated/node-v24-backlog.jsonis the internal tier-specific work queue. It separates verification, implementation, explicit-refusal replacement, and partial-surface audit work, and prioritizes stable Node APIs above experimental, deprecated, and legacy APIs.docs/src/generated/node-v24-compatibility.jsonis the stripped public artifact consumed by the docs website. It contains compiler-relevant runtime APIs, statuses, verification bases, and user-facing details; documentation, metadata, command-line/configuration entries, and rows that are N/A for native execution remain internal.
Statuses are evidence-aware: supported and partial require test evidence; refused requires an explicit compiler diagnostic or native throwing stub; not-implemented is the actionable backlog for an owned API family with no implementation match; by-design records an architectural exclusion; unreviewed still needs classification; and not-applicable is not a runtime API for that execution tier.
Run pnpm node-compat:backlog from the repository root for a summary. The filters --tier, --action, --priority, --chapter, and --status compose; use --format=json or --format=tsv for tooling.
Run pnpm node-compat from the repository root after changing the Node pin or the support manifest. pnpm node-compat:check is the offline drift/evidence gate; pnpm --filter @internal/compatibility check:upstream additionally verifies the pinned upstream inputs over the network.