crypto: fix error handling in KeyObject.export

[tniessen]

This change only affects KeyObject.export():

crypto.generateKeyPairSync('rsa', { modulusLength: 1024 }).publicKey.export()

Old error message:

TypeError: Cannot destructure property `format` of 'undefined' or 'null'.
    at parseKeyFormatAndType (internal/crypto/keys.js:154:48)
    at parseKeyEncoding (internal/crypto/keys.js:180:7)
    at parsePublicKeyEncoding (internal/crypto/keys.js:212:10)
    at PublicKeyObject.export (internal/crypto/keys.js:94:9)

New error message:

TypeError [ERR_INVALID_ARG_TYPE]: The "options" argument must be of type object. Received type undefined
    at parseKeyEncoding (internal/crypto/keys.js:176:11)
    at parsePublicKeyEncoding (internal/crypto/keys.js:215:10)
    at PublicKeyObject.export (internal/crypto/keys.js:94:9)

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• 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/2770/pipeline

[sam-github]

semver-major, isn't it?

[tniessen]

I prefer to think of this as a bug-fix of a (so far) rarely used API, but yeah, I guess it is technically a breaking change...

[addaleax]

I’m okay with semver-patch.

[sam-github]

I thought the policy was "all error message changes are semver-major", so that we didn't have to guess the impact, we just called the changes semver-major (except by decision of TSC, they can always overrule anything if deemed in best interest of node).

Did that change? Do I misremember?

[tniessen]

@sam-github I think that is still true, so unless the TSC is in favor of semver-patch (@addaleax, maybe others), this should technically be semver-major. (I forgot to add the label in the first place, sorry.)

[panva]

Even for what i’d call missed input assertion or an “uncaught”? Interesting

[BridgeAR]

@nodejs/tsc PTAL about semverness.

[sam-github]

I can't find current policy. I find https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md#breaking-changes-and-deprecations

Changing error messages for errors without error code;

That this is in the list implies that such changes are at least sometimes semver-major, but not that they are always. Maybe? IANAL.

Personally, I think its unlikely to cause trouble to introduce this as a patch.

But, my understanding was that historically Node.js guessing an error message change wouldn't cause trouble didn't work out so well, so .code was introduced, and error message changes were considered semver-major until a .code is introduced, at which point they become informational. My understanding has been wrong before, though.

[Trott]

If we're trying to get a majority of TSC to 👍 landing this on master without the semver-major label: I'm OK with patch for this. 👍

[tniessen]

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

[BridgeAR]

Re-run CI https://ci.nodejs.org/job/node-test-pull-request/21359/

[tniessen]

Thanks for reviewing, everyone! Landed in 3afa5d7.

@nodejs/tsc Based on the previous discussion, I am not adding the semver-major label. Feel free to add it if you think it is appropriate.

[BridgeAR]

This does not land cleanly on v11. It also seems that even fixing the conflict is not enough as a test fails in that case. It would be nice if this would be manually backported if it should be backported at all.

[tniessen]

@BridgeAR #26688