Ref: nodejs/node@61b20f60a39

(cherry picked from commit 432172c)
Co-Authored-By: GPT-5.3-Codex <[email protected]>

Ref: nodejs/node@69df688fff4

Co-Authored-By: GPT-5.3-Codex <[email protected]>
(cherry picked from commit ce40736)

The error thrown for an unsupported OKP (Ed448) JWK changed from 'Invalid JWK data' to the more specific 'Invalid JWK OKP key'.

Ref: nodejs/node#62499
(cherry picked from commit 5718143)

Ref: nodejs/node@677ca7e76c9

Co-Authored-By: GPT-5.3-Codex <[email protected]>
(cherry picked from commit 4d514ff)

Ref: nodejs/node@69df688fff4

Co-Authored-By: GPT-5.3-Codex <[email protected]>

This test synthesizes fake V8-serialized messages with the serialization format version hardcoded to 15 (0x0f). Electron bundles Chromium's V8, whose value-serializer format version is 16 (0x10), so the hardcoded headers are not recognized by the test runner's deserializer and the bytes fall through the UTF-8 stdout path (0xff -> U+FFFD), failing the assertions. The version difference is environmental and cannot be reconciled without re-patching the test on every V8 bump.

The failing subtests were introduced upstream in nodejs/node#62704 (test_runner: avoid hanging on incomplete v8 frames).

Chromium 148's BoringSSL does not implement ML-KEM/ML-DSA/SLH-DSA, which upstream wired up for BoringSSL in nodejs/node#63255. Skip or disable the affected tests on BoringSSL for this Electron version.

Ref: nodejs/node#63255

Co-Authored-By: Claude <[email protected]>