This will be a start to generalize all argument validation
errors. As currently we throw ARG/OPT, OUT_OF_RANGE, and other more
specific errors.
The OPT errors didn't bring much to the errors as it's just another
variant of ARG error which is sometimes more confusing (some of our code
used OPT errors to denote just argument validation errors presumably
because of similarity of OPT to 'option' and not 'options-object')
and they don't specify the name of the options object where the invalid
value is located. Much better approach would be to just specify path
to the invalid value in the name of the value as it is done in this PR
(i.e. 'options.format', 'options.publicKey.type' etc)
Also since this decreases a variety of errors we have it'd be easier to
reuse validation code across the codebase.
Refs: https://github.com/nodejs/node/pull/31251
Refs: https://github.com/nodejs/node/pull/34070#discussion_r467251009
Signed-off-by: Denys Otrishko <shishugi@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/34682
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This completely refactors the `expectsError` behavior: so far it's
almost identical to `assert.throws(fn, object)` in case it was used
with a function as first argument. It had a magical property check
that allowed to verify a functions `type` in case `type` was passed
used in the validation object. This pattern is now completely removed
and `assert.throws()` should be used instead.
The main intent for `common.expectsError()` is to verify error cases
for callback based APIs. This is now more flexible by accepting all
validation possibilites that `assert.throws()` accepts as well. No
magical properties exist anymore. This reduces surprising behavior
for developers who are not used to the Node.js core code base.
This has the side effect that `common` is used significantly less
frequent.
PR-URL: https://github.com/nodejs/node/pull/31092
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
The current API is somewhat confusing at times and simpler usage is
possible. This overloads the arguments further to accept objects
with deprecation codes as property keys. It also adds documentation
for the different possible styles.
Besides that it is now going to validate for the code being present
in case of deprecations but not for other cases. The former validation
was not consistent as it only validated some cases and accepted
undefined instead of `common.noWarnCode`. This check is removed due to
the lack of consistency. `common.noWarnCode` is completely removed
due to just being sugar for `undefined`.
This also verifies that the warning order is identical to the order
in which they are triggered.
PR-URL: https://github.com/nodejs/node/pull/25251
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Restricting the authentication tag length and calling update or
setAAD before setAuthTag caused an incorrect authentication tag to
be passed to OpenSSL: The auth_tag_len_ field was already set, so
the implementation assumed that the tag itself was known as well.
PR-URL: https://github.com/nodejs/node/pull/22828
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
The APIs were probably exposed by accident. getAuthTag and setAuthTag
are not a usual getter/setter pair: Getting the authentication tag
only makes sense in the context of encryption, setting it only makes
sense in the context of decryption. Currently, both functions throw.
Neither has been documented publicly.
PR-URL: https://github.com/nodejs/node/pull/22126
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Before this commit it computed `(1<<(8*(15-iv_len)))-1` for `iv_len>=11`
and that reduces to `(1<<32)-1` for `iv_len==11`. Left-shifting past
the sign bit and overflowing a signed integral type are both undefined
behaviors.
This commit switches to fixed values and restricts the `iv_len==11`
case to `INT_MAX`, as was already the case for all `iv_len<=10`.
PR-URL: https://github.com/nodejs/node/pull/21462
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
The current implementation performs limited checks only and silently
ignores superfluous bytes of the authentication tag. This change makes
setAuthTag throw when
- the user-specified authTagLength does not match the actual tag length,
especially when the authentication tag is longer than 16 bytes, and
when
- the mode is GCM, no authTagLength option has been specified and the
tag length is not a valid GCM tag length.
This change makes the conditional assignment in SetAuthTag unnecessary,
which is replaced with a CHECK.
Refs: https://github.com/nodejs/node/pull/17825
PR-URL: https://github.com/nodejs/node/pull/20040
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Yihong Wang <yh.wang@ibm.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
This commit adds a deprecation code to expectWarning and updates the
function to check the passed code against the code property on the
warning object.
Not all warnings have a deprecation code so for those that don't an
explicit code of common.noWarnCode is required. Passing this skips the
assertion of the code.
PR-URL: https://github.com/nodejs/node/pull/19474
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
* Remove needless RegExp flag
In fixed case, `/g` flag is needless in the boolean context.
* Remove needless RegExp capturing
Use non-capturing grouping or remove capturing completely when:
* capturing is useless per se, e.g. in test() check;
* captured groups are not used afterward at all;
* some of the later captured groups are not used afterward.
* Use test, not match/exec in boolean context
match() and exec() return a complicated object,
unneeded in a boolean context.
* Do not needlessly repeat RegExp creation
This commit takes RegExp creation out of cycles and other repetitions.
As long as the RegExp does not use /g flag and match indices,
we are safe here.
In tests, this fix hardly gives a significant performance gain,
but it increases clarity and maintainability,
reassuring some RegExps to be identical.
RegExp in functions are not taken out of their functions:
while these functions are called many times
and their RegExps are recreated with each call,
the performance gain in test cases
does not seem to be worth decreasing function self-dependency.
PR-URL: https://github.com/nodejs/node/pull/13770
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Fix a regression introduced in commit 2996b5c ("crypto: Allow GCM
ciphers to have a longer IV length") from April 2016 where a misplaced
parenthesis in a 'is ECB cipher?' check made it possible to use empty
IVs with non-ECB ciphers.
Also fix some exit bugs in test/parallel/test-crypto-authenticated.js
that were introduced in commit 4a40832 ("test: cleanup IIFE tests")
where removing the IFFEs made the test exit prematurely instead of just
skipping subtests.
PR-URL: https://github.com/nodejs/node/pull/9032
Refs: https://github.com/nodejs/node/pull/6376
Refs: https://github.com/nodejs/node/issues/9024
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Reviewed-By: Shigeki Ohtsu <ohtsu@ohtsu.org>
A number of test files use IIFEs to separate distinct tests from
each other in the same file. The project has been moving toward
using block scopes and let/const in favor of IIFEs. This commit
moves IIFE tests to block scopes. Some additional cleanup such
as use of strictEqual() and common.mustCall() is also included.
PR-URL: https://github.com/nodejs/node/pull/7694
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Marco Ippolito