crypto: fail early if passphrase is too long

[tniessen]

This causes OpenSSL to fail early if the decryption passphrase is too long, and produces a somewhat helpful error message. OpenSSL gives us a buffer of limited size (currently 1024 bytes), so there is no way to pass longer passphrases.

Refs: #25208

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[nodejs-github-bot]

@tniessen build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/3104/pipeline

[tniessen]

This was @sam-github's idea in #25208 (comment), thanks Sam! :)

[tniessen]

I think this is technically semver-major? So cc @nodejs/tsc

[rvagg]

Oooo, tricky. Where does this fail without this fix and what does that failure look like? It's not from the createPrivateKey() call at the moment as far as I can tell.
I'm tempted to say this is a bugfix and therefore not breaking, but we've been very careful with error messages / codes etc. in the last few years so maybe we're forced to make it semver-major depending on what failure looks like. If it's something like a silent failure then I'd say it's a bugfix and can be semver-patch.

[tniessen]

@rvagg It is indeed tricky! The failure without this patch is unpredictable. createPrivateKey might fail with the message bad decrypt if the PKCS#7 padding is invalid after decryption, this is the most likely behavior. However, if the PKCS#7 padding matches by chance, it can also result in an asn1 encoding error. And there is a tiny chance that both decryption and ASN.1 decoding succeed (either correctly or incorrectly, but without producing an error), and some other API call would randomly fail later when trying to use the key.

Note that this should also be an extremely rare case, supplying such a long passphrase does not make sense since the entropy of the passphrase would far exceed the entropy of the derived decryption key.

[rvagg]

OK, so I'm going to go out on a limb and suggest that those failure modes mean we have bugs in our interface and therefore this should be semver-patch.

Anyone else have an opinion? @tniessen what's your position?

[tniessen]

I'm usually leaning towards semver-patch too easily 😅 This does change the error message and code, but on the other hand, it also provides a stable solution instead of the current unpredictable behavior. Personally, I feel that this should land on all release lines where that is possible, simply to get rid of the unpredictability, but I am also fine with a TSC decision to treat this as semver-major.

those failure modes mean we have bugs in our interface and therefore this should be semver-patch.

From that perspective, this certainly is a bugfix, we should not have accepted passphrases that do not fit into the buffer in the first place.

[sam-github]

We've been more lax about semver-major's recently. In this case, someone would have to be relying on passing a passphrase that is too large, and it getting truncated... which is pretty obscure. I'd be OK with semver-patch, mostly because I don't want this to float until the fall for 13.x, continually causing backport conflict.

[tniessen]

I removed the semver-major label, feel free to chime in @nodejs/tsc.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/22133/

[danbev]

Re-build of failing node-test-commit-linux (✔️)

[BridgeAR]

Landed in 73bca57 🎉