[robobun]

Problem

• crypto.diffieHellman() accepts only KeyObjects. Key data throws ERR_INVALID_ARG_VALUE: The property 'options.privateKey' is invalid. Node accepts it since v26.1.0 (crypto: accept key data in crypto.diffieHellman() and cleanup DH jobs nodejs/node#62527).
• Cause: DhJobCtx::fromJS (src/jsc/bindings/node/crypto/CryptoDhJob.cpp:80) downcasts both to JSKeyObject.
• KeyObject::prepareAsymmetricKey hardcodes the name key and returns a pointer that a second key's getter can invalidate.

Fix

• prepareAsymmetricKey(value, mode, name) only validates and returns the owner of the key bytes. importPreparedKey reads them. diffieHellman prepares both keys, then imports both, like Node.
• The 7 other sites call getAsymmetricKeyFromJS (both steps). Sign#sign, privateEncrypt and privateDecrypt pass Node's name privateKey.
• The EC JWK import checks for an exception after it decodes d: a vm timeout there crashed, on main too.
• Verified: test/js/node/crypto/node-crypto.test.js, crypto.key-objects.test.ts (74 fail on main), upstream test-crypto-dh-stateless.js, 159 vendored crypto tests. Self-reviewed: 6 concerns raised, 3 addressed.

Background

• Key data is a key that is not a KeyObject: PEM text or { key, format }.
• Node validates both keys before it reads either, and a getter on one key can change the other.
• Considered copying the two-step block into DhJobCtx::fromJS: errors would say key.key, Node's test requires options.privateKey.key.

Downsides

• Error text changes at 10 APIs (options.format becomes key.format). Incompatible KeyObjects throw ERR_CRYPTO_INCOMPATIBLE_KEY, a failed derive ERR_OSSL_EVP_*.
• Release text grows 1,872 bytes. With KeyObjects: diffieHellman 3 to 2 mi_malloc, 2,076 to 2,007 instructions. createPublicKey 802 to 803.
• 68 of 250 probed diffieHellman results differ from Node (230 on main): BoringSSL codes, JWK and raw import text.

Notes

Reproduction (Node v26.3.0 prints ok five times, Bun 1.4.3 prints ok once):

import crypto from "node:crypto";
const a = crypto.generateKeyPairSync("x25519");
const b = crypto.generateKeyPairSync("x25519");
const ref = crypto.diffieHellman({ privateKey: a.privateKey, publicKey: b.publicKey }).toString("hex");
const t = f => { try { return f() === ref ? "ok" : "WRONG SECRET"; } catch (e) { return `${e.code}: ${e.message.slice(0, 60)}`; } };
const dh = (privateKey, publicKey) => crypto.diffieHellman({ privateKey, publicKey }).toString("hex");
console.log(t(() => dh(a.privateKey, b.publicKey)));
console.log(t(() => dh({ key: a.privateKey.export({ format: "jwk" }), format: "jwk" }, b.publicKey)));
console.log(t(() => dh(a.privateKey, { key: b.publicKey.export({ format: "jwk" }), format: "jwk" })));
console.log(t(() => dh(a.privateKey.export({ type: "pkcs8", format: "pem" }), b.publicKey.export({ type: "spki", format: "pem" }))));
console.log(t(() => dh({ key: a.privateKey.export({ type: "pkcs8", format: "der" }), format: "der", type: "pkcs8" }, { key: b.publicKey.export({ type: "spki", format: "der" }), format: "der", type: "spki" })));

What diffieHellman does now, in Node's order

1. options.privateKey == null, then options.publicKey == null: ERR_INVALID_ARG_VALUE.
2. A KeyObject privateKey that is not private, or a secret KeyObject publicKey: ERR_CRYPTO_INVALID_KEY_OBJECT_TYPE.
3. Two KeyObjects of different types, or of a type other than dh, ec, x448, x25519: ERR_CRYPTO_INCOMPATIBLE_KEY (Incompatible key types for Diffie-Hellman: ec and x25519). Two valid KeyObjects return here. No new code runs for them.
4. Validate publicKey key data, then validate privateKey key data. Then import publicKey, then import privateKey. Each error throws synchronously, also when a callback is given.
5. The derive. A failure reports the first OpenSSL error (ERR_OSSL_EVP_DIFFERENT_PARAMETERS, ERR_OSSL_EVP_DIFFERENT_KEY_TYPES, ERR_OSSL_EVP_OPERATION_NOT_SUPPORTED_FOR_THIS_KEYTYPE, ERR_OSSL_EVP_INVALID_PEER_KEY). These are the codes that the Node test expects for BoringSSL.

Two changes for callers that pass KeyObjects and get an error

• Two KeyObjects of incompatible types: ERR_CRYPTO_INCOMPATIBLE_KEY, class Error. Before: ERR_INVALID_ARG_VALUE, class TypeError, The property 'options.privateKey' must be a supported key type.
• A failed derive (for example P-256 with P-384): ERR_OSSL_EVP_DIFFERENT_PARAMETERS. Before: ERR_CRYPTO_OPERATION_FAILED: diffieHellman operation failed. If OpenSSL reports no error, the fallback is ERR_CRYPTO_OPERATION_FAILED: Deriving bits failed, which is Node's text.

Names. The second column is name. Each path is name, name.key, name.format, name.type, name.passphrase, name.asymmetricKeyType or name.namedCurve.

Function	Node v26.3.0 and this PR	Before
diffieHellman	options.privateKey, options.publicKey	key data rejected
Sign#sign, privateEncrypt, privateDecrypt	privateKey	key, and options.format / options.type / options.passphrase
createPublicKey, createPrivateKey, sign, verify, Verify#verify, publicEncrypt, publicDecrypt	key	key, and options.format / options.type / options.passphrase
KeyObject#export	options.<option>	same
generateKeyPair	options.publicKeyEncoding.<option>, options.privateKeyEncoding.<option>	same

makeOptionString(prefix, option) now renders <prefix>.<option>, which is Node's option() helper after nodejs/node#62527. #38415 makes that change with a fixed key prefix. This PR contains it with the name of the caller, so #38415 is not needed after this PR.

One text outside node:crypto changes. tls.createSecureContext({ key: [{ pem, passphrase: 1 }] }) reports The property 'key.passphrase' is invalid. Before: The property 'options.passphrase' is invalid. Node reports ERR_INVALID_ARG_TYPE for options.passphrase from its own tls check, which Bun does not have for a passphrase inside the key array.

Two guards changed on lines that this PR rewrites, so that the new diffieHellman forms do not inherit them. A function is not an options object (Node tests typeof key === 'object'). A format that is not a string is not converted to one (Node compares with ===). Sign#sign had its own check for a number or a boolean key, with a different list of types. It is gone, so that key gets the same message as in Node.

The crash in the EC JWK import. getKeyObjectHandleFromJwk decodes d and used the result with no exception check. JSC delivers a termination (a vm script timeout, worker.terminate()) at the next exception check, so the decode can return null. On main this loop ends with Segmentation fault at address 0x10 in 3 of 3 runs: vm.runInContext("for (;;) run();", context, { timeout: 1 }) with run = () => crypto.createPrivateKey({ key: ecPrivateJwk, format: "jwk" }). With this PR diffieHellman reaches the same line, so the check is part of it. #32910 reworks the OKP branch of that function and does not touch this line. After the fix, 19 key forms (every diffieHellman form, and JWK keys through sign, verify, createPrivateKey, privateDecrypt) survive 120 timeouts each on the debug build with ASAN.

The 68 probe results that still differ from Node v26.3.0. The probe is 125 inputs, each with and without a callback. None of the 68 is specific to diffieHellman. Each is the error that createPrivateKey or createPublicKey gives for the same input in Bun. No input returns a secret in one runtime and throws in the other (50 such results on main).

• 44: BoringSSL and OpenSSL 3 report different codes for a key that does not parse, and for a derive that fails (ERR_OSSL_PEM_NO_START_LINE and ERR_OSSL_UNSUPPORTED). An encrypted key with no passphrase is ERR_MISSING_PASSPHRASE in Bun.
• 14: JWK import reports The property 'key.kty' must be one of ... where Node reports ERR_CRYPTO_INVALID_JWK. A public JWK as privateKey fails in the import, not in the derive. node:crypto: import OKP JWKs like Node 26, in one raw-key arm shared with AKP #32910 reworks that import, so this PR does not change its messages.
• 10: wording of the raw key import (The argument 'key' Invalid key data. Received undefined where Node reports Invalid key data) and of one expected-type list, which node:crypto: render prepareAsymmetricKey ERR_INVALID_ARG_TYPE lists like Node #38431 changes.

Not changed here, and the same on main: the order of checks at the other call sites. Sign#sign checks padding, Verify#verify checks the signature and publicEncrypt checks oaepLabel before the key, where Node checks the key first. #40550 (encapsulate and decapsulate) adds one more copy of the two-step block and can call getAsymmetricKeyFromJS. #38431, #38690, #43508 and #36166 edit lines inside prepareAsymmetricKey and need a rebase after this PR.

Measurements. Release builds of main at 408c937 with and without this change, linux-x64. Two later commits are not in these builds: getAsymmetricKeysFromJS took the two steps out of the diffieHellman key data path, and Sign#sign lost a pre-check. No measured path except diffieHellman(PEM, PEM) runs that code, and text can differ by tens of bytes. gdb counts on a fixed script, with ASLR off and the same environment for both binaries. perf and valgrind are not installed on the build machine.

• diffieHellman(KeyObject, KeyObject), sync: 2 mi_malloc per call (base 3. Calls 20 to 59, x25519). The unused WTF::Vector in DhJobCtx::runTask is gone.
• diffieHellman(KeyObject, KeyObject), sync: 2,007 instructions outside the derive (base 2,076. stepi, calls 20 to 23 give the same count).
• diffieHellman(KeyObject, KeyObject, callback): 4 mi_malloc per call (base 5). DhJobCtx 48 B requested and 48 B usable (base 40 and 48). 1 work-pool job per call (base 1). 1 syscall on the JS thread per call (base 1).
• createPublicKey(KeyObject): 803 instructions (base 802). crypto.sign(KeyObject): 159,534 (base 159,532). crypto.verify(KeyObject): 630,196 (base 630,189). createPublicKey(PEM): 5,592 (base 5,590). Fourth warm call, one fixed Ed25519 key. importPreparedKey is entered 0 times for a KeyObject argument.
• createPublicKey({ key, format: 'pem' }): 18 mi_malloc per call (base 20). The two option names (options.format, options.type) are now built only for an error. createPublicKey(pem): 16 (base 16). sign(pem): 32 (base 32).
• diffieHellman(PEM, PEM), sync: 42 mi_malloc and 0 syscalls per call. createPrivateKey + createPublicKey + diffieHellman(KeyObject, KeyObject) on the base: 43 and 0.
• Release text: 105,954,359 B (base 105,952,487, +1,872 B, llvm-size). jsDiffieHellman: 1,949 B (base 1,836). The compiler now inlines DhJobCtx::runTask (138 B) into it.
• getAsymmetricKeyFromJS is ALWAYS_INLINE. As an out-of-line function it gives text 432 B below the base, and 28 more instructions for each key argument (createPublicKey(KeyObject) 830).
• Host functions +0, job types +0, src/js bytes +0. The binding table, node_crypto_binding.rs and src/js have no diff.
• Key descriptor on the stack: 72 B (base 88 B). It cannot be heap allocated (WTF_FORBID_HEAP_ALLOCATION). The split adds 0 heap allocations.
• Error text of the 10 other APIs, 120 inputs: 10 differ from Node (base 71). All 10 are the expected-type list of a raw key, which node:crypto: render prepareAsymmetricKey ERR_INVALID_ARG_TYPE lists like Node #38431 changes.
• Getters and Proxies that change one key while the other is prepared, 754 cases: 0 differ from Node without a callback, 0 with a callback. If both keys are invalid, the same key wins as in Node in 7 of 7 cases. 0 ASAN reports on the debug build.
• Wall clock, bench/crypto/diffie-hellman.mjs case diffieHellman X25519 - KeyObjects, median of 8 interleaved runs: base 55.64 us, PR 55.46 us. Two runs of the base differ by 11.8 %, and the 8 runs of one binary spread over 42 %. This shows no difference.

Self-review. The review did not run to its end. These are the concerns that it had raised and probed.

• Addressed: the null dereference in the EC JWK import (the exception check, and the test with the vm timeout).
• Addressed: a validated key must keep its Buffers alive when a GC runs in a getter of the other key. It does. The new test forces a GC in that getter. It also passes with BUN_JSC_collectContinuously=1.
• Not changed: LeakSanitizer reports at process.exit() for the Buffer that holds a decoded PEM string, and for the results of jobs in flight. Main reports the same for crypto.sign(pem) and for KeyObject jobs.
• Not changed: a setter on Error.prototype.reason runs when the job builds its error. It needs prototype pollution, and sign and generateKeyPair build their errors the same way.
• Addressed: the two steps were public, and a caller had to pass the same mode to both. They are private now. getAsymmetricKeyFromJS runs them for one key and getAsymmetricKeysFromJS for two keys, in Node's order.
• Not changed: ALWAYS_INLINE on the one-call wrapper. The two costs are in the measurements above.

Suites run on the debug build with this change

• test/js/node/crypto/node-crypto.test.js and crypto.key-objects.test.ts: 389 pass. On main 64 and 10 of them fail.
• test/js/node/crypto/: 0 fail (with a longer per-test timeout, for the RSA key generation tests on a debug build).
• test/js/node/test/parallel/test-crypto-* and test-webcrypto-*: 159 of 159 exit 0. test-crypto-dh-stateless.js, test-crypto-key-objects.js and test-crypto-sign-verify.js exit 1 on main with the updated files.
• The new diffieHellman and key name tests, and six vendored key tests, also pass with BUN_JSC_validateExceptionChecks=1.

Vendored tests. test-crypto-dh-stateless.js was a block-commented old copy (#35408 lists it). It is now the Node v26.3.0 file. The only edit is the first word of two comments, which is Note here. Its finite-field DH and X448 cases skip themselves for BoringSSL. One line each in test-crypto-key-objects.js (key.type) and test-crypto-sign-verify.js (privateKey.key) goes back to the upstream text.

---

no test proof · iteration 1 · platform-specific test(s) that do not run on this machine, deferring to CI, which covers all platforms: test/js/node/crypto/crypto.key-objects.test.ts

[robobun]

Status: ready for review (#45335).

Reproduction: the script in the PR notes calls crypto.diffieHellman() with two KeyObjects, then with a JWK private key, a JWK public key, PEM keys and DER keys. Node v26.3.0 prints ok five times. Bun 1.4.3 prints ok once and throws ERR_INVALID_ARG_VALUE: The property 'options.privateKey' is invalid for the key data. With this PR, Bun prints ok five times.

[robobun]

^{Updated 9:54 AM PT - Oct 15th, 2026}

✅ @robobun, your commit 5c471e571701cc33dbe28230be189567c2c4faed passed in Build #125969! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 45335

That installs a local version of the PR into your bun-45335 executable, so you can run:

bun-45335 --bun

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: oven-sh/bun/.coderabbit.yaml
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 084c3ff8-9ceb-4714-824a-7009b7588fdc

📥 Commits

Reviewing files that changed from the base of the PR and between 8b85476 and 5c471e5.

📒 Files selected for processing: 6

• src/jsc/bindings/node/crypto/CryptoDhJob.cpp
• src/jsc/bindings/node/crypto/CryptoUtil.cpp
• src/jsc/bindings/node/crypto/JSSign.cpp
• src/jsc/bindings/node/crypto/KeyObject.cpp
• src/jsc/bindings/node/crypto/KeyObject.h
• test/js/node/crypto/crypto.key-objects.test.ts

💤 Files with no reviewable changes: 1

• src/jsc/bindings/node/crypto/JSSign.cpp

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 1 remain after this review.

Walkthrough

The change defers asymmetric-key import, routes crypto APIs through shared KeyObject conversion helpers, and expands Diffie-Hellman key-data handling and error reporting. Tests cover input formats, getter ordering, and synchronous and callback behavior. Two X25519 benchmarks compare KeyObject and PEM inputs.

Changes

Crypto Key Handling

Layer / File(s)	Summary
Deferred asymmetric-key preparation and import src/jsc/bindings/node/crypto/KeyObject.*, src/jsc/bindings/node/crypto/CryptoUtil.*	PreparedAsymmetricKey retains key-data and passphrase owners for later import. Preparation validates JWK and raw-key options, while import handles JWK, raw, and encoded formats. Option parsing builds contextual property paths and can return the passphrase owner.
Crypto API key conversion and validation paths src/jsc/bindings/node/crypto/CryptoKeys.cpp, CryptoSignJob.cpp, JSCipher.cpp, JSSign.cpp, JSVerify.cpp, CryptoGenKeyPair.cpp, test/js/node/crypto/crypto.key-objects.test.ts, test/js/node/test/parallel/test-crypto-key-objects.js, test/js/node/test/parallel/test-crypto-sign-verify.js	Key creation, signing, verification, and RSA operations use shared key-conversion helpers. Encoding errors use contextual option paths. Tests cover key-read ordering, validation names, and encrypted PEM handling through TLS.
Diffie-Hellman inputs, derivation, and validation src/jsc/bindings/ErrorCode.*, src/jsc/bindings/node/crypto/CryptoDhJob.*, test/js/node/crypto/node-crypto.test.js, test/js/node/test/parallel/test-crypto-dh-stateless.js, bench/crypto/diffie-hellman.mjs	Diffie-Hellman accepts key data as well as KeyObjects, and reports incompatible key types with a dedicated error. Derivation errors retain OpenSSL error codes. Tests cover key formats, validation order, and synchronous and callback behavior; benchmarks compare X25519 KeyObject and PEM inputs.

Suggested reviewers: jarred-sumner, dylan-conway

Priority: ➖ Normal

Merge Risk: ⚪ Minimal · up to 5c471

No confirmed issue remains that would block merging after normal checks.

Pre-merge checks: 4

Passed checks: 4 passed

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Title check		The title clearly and concisely describes the main changes: accepting key data in crypto.diffieHellman and separating key preparation from import.
Description check		The description provides a detailed explanation of the problem, implementation, behavior changes, testing, measurements, and known differences. It does not use the exact template headings, but it incl…

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

I worked on the same report in parallel, on top of the first commit of this branch. This PR covers the fix, so I did not open a second PR. My branch has four changes that this PR does not have. Take them here, or leave them for a follow-up.

Diff against the head of this PR: https://github.com/oven-sh/bun/compare/robobun/1899ee18/dh-stateless-key-data..robobun/dd281612/dh-stateless-key-data

1. Check order at the other call sites (cfe87b4). The PR body lists this as not changed. Sign#sign, Verify#verify, publicEncrypt, publicDecrypt, privateEncrypt and privateDecrypt call prepareAsymmetricKey first, then validate their other options (and the signature or the buffer), then call importPreparedKey. That is the order of Node's lib/internal/crypto/sig.js and cipher.js.

• 37 calls with two invalid arguments: the same error wins as in Node v26.3.0 in 36. With the order of main it is 19.
• The one that differs: publicEncrypt({ key: 'not a key', oaepHash: 'nope' }, buffer) reports ERR_OSSL_EVP_INVALID_DIGEST, and Node reports the key. The digest lookup stays before the import. Node reads a public key in the private RSA functions and Bun does not, so the upstream case privateDecrypt({ key: <public PEM>, oaepHash: 'Hello world' }) in test-crypto-rsa-dsa.js needs the digest error first.
• The RSA functions convert the buffer before the import and take its bytes after it, because the getters of a JWK run during the import.
• The !options.isCell() check in Sign#sign is gone. prepareAsymmetricKey reports that case with Node's text.
• Cost for a KeyObject against main, in instructions before the crypto operation, release build: Sign#sign +10, Verify#verify +11, publicEncrypt +27. The allocation counts do not change.

2. No default for the name (f17964f). getAsymmetricKeyFromJS takes the name at each call site. getPrivateKeyFromJS and getPublicOrPrivateKeyFromJS are gone.

3. The prepared key carries its mode (f17964f, 01e06bd). importPreparedKey takes no mode, so the two steps cannot disagree. It tests keyData inline and calls the out-of-line importPreparedKeyData only for key data, so a KeyObject pays no call at the sites of item 1.

4. Shared validators (f17964f). The JWK and raw checks in prepareAsymmetricKey call V::validateObject(value, name, "key") and V::validateString(value, name, "asymmetricKeyType"). The new overloads build the dotted name only for the error.

Tests on the branch that this PR does not have (5711a0c):

• crypto.diffieHellman: the util.promisify form, CryptoKeys with one DEP0203 warning, a key buffer that a getter makes shorter, both keys read before a call with a callback returns, and three key data rows in the LeakSanitizer table.
• The other functions: the order cases of item 1, JWK and raw keys through each function, and publicEncrypt with a JWK getter that rewrites or detaches the input buffer.

On the debug build of the branch, test/js/node/crypto/node-crypto.test.js (284 tests), crypto.key-objects.test.ts (120 tests) and the 120 vendored test-crypto-* files pass.

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Beyond the inline findings, I also checked the lifetime of the new PreparedAsymmetricKey across the second key's getters in dhJobCtxFromKeyData: it holds only stack-resident JSValues/cell pointers (no spans), and importPreparedKey reads the key and passphrase bytes under EnsureStillAliveScope only after both prepares have run, so a getter that detaches a buffer yields an empty span rather than a stale pointer. I also checked the two-KeyObject fast path: it is unchanged apart from the new ERR_CRYPTO_INCOMPATIBLE_KEY error.

Extended reasoning...

The change rewires key preparation across ten node:crypto entry points in the C++ bindings and adds a key-data path to crypto.diffieHellman, which is crypto-sensitive code; the inline findings already signal that a human should look, and this note only records the GC/detach lifetime concern that was examined and ruled out from the diff.

[claude]

Still open from earlier reviews (3):

• Unresolved: 3 minor or pre-existing.

[claude]

🔴 pre-existing: callers of Sign#sign with a bad key and a bad option get the option error where Node reports the key error. JSSign.cpp:433-443 runs getPadding, getSaltLength and getDSASigEnc before getPrivateKeyFromJS, while Node's Sign.prototype.sign calls preparePrivateKey(options, 'privateKey') first and reads padding afterwards. Fix: prepare the key before the padding, saltLength and dsaEncoding options in Sign#sign, and in Verify#verify prepare the key before the signature argument (JSVerify.cpp:330-333), so the error that wins on doubly-invalid input matches Node. Same pattern at 2 sites (JSSign.cpp:443, JSVerify.cpp:333).

Why this was flagged

Input: createSign('sha256').update(data).sign({ key: 1, padding: 'x' }). jsSignProtoFuncSign at src/jsc/bindings/node/crypto/JSSign.cpp:433 calls getPadding, which reads options.padding (CryptoUtil.cpp:442-458) and throws ERR_INVALID_ARG_VALUE "The property 'options.padding' is invalid" before the key is validated at JSSign.cpp:443. Node's lib/internal/crypto/sig.js Sign.prototype.sign calls preparePrivateKey(options, 'privateKey') first, so Node throws ERR_INVALID_ARG_TYPE for "privateKey.key" (or "privateKey") and never reaches getPadding. The same inversion exists in JSVerify.cpp:330-333, where the signature argument is converted before the key, while Node's Verify.prototype.verify prepares the key before getArrayBufferOnView(signature). The base branch has the same order in both files; this PR rewrites the key call at both sites without moving it ahead of the option reads, so the doubly-invalid case still diverges from Node. Only the error that wins differs; valid input is unaffected.

Verification: src/jsc/bindings/node/crypto/JSSign.cpp:433-444 runs getPadding, getSaltLength, getDSASigEnc and only then KeyObject::getPrivateKeyFromJS at line 443. getIntOption (CryptoUtil.cpp:438-466) throws ERR_INVALID_ARG_VALUE for options.padding, so for { key: 1, padding: 'x' } the padding error wins before the key is examined; Node calls preparePrivateKey first. JSVerify.cpp:330 reads the signature before the key at line 333. The base branch had the identical order.

[robobun]

This order is on main too, and the PR notes list it under "Not changed here". The suggested move is not enough, so I kept it out.

Node's order in Sign#sign is: validate the key, read padding, saltLength and dsaEncoding, then import the key. Checked on v26.3.0:

• sign({ key: 1, padding: 'x' }) reports privateKey.key.
• sign({ key: 'garbage', padding: 'x' }) reports options.padding.
• verify({ key: 1 }, 1) reports key.key.
• verify('garbage', 1) reports signature.

Bun reports the option or the signature in all four cases. A call to getPrivateKeyFromJS ahead of the option reads fixes the first case of each pair and breaks the second, because that helper also imports the key.

The exact order needs the two steps around the option reads, at six call sites (Sign#sign, Verify#verify, the RSA functions, one-shot sign and verify). That changes which error wins in six functions, so it is a separate change.

[Jarred-Sumner]

This is Claude (an AI assistant) commenting on Jarred's behalf.

Another fix for the same crash went in with #46021, which is merged. Closing as superseded.