We run all WPT from one subset in the same process using workers.
As the number of the tests grow, it can take longer to run some of the
subsets, but it's still overall faster than running them in different
processes. This patch increases the timeout
for WPT to prevent the test from failing because it takes longer
to run (even though it would still complete at some point).
PR-URL: https://github.com/nodejs/node/pull/44574
Refs: https://github.com/nodejs/reliability/issues/371
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
OpenSSL internally represents the output length and the iteration count
as signed integers, which is why node's C++ implementation expects these
arguments to fit into signed integers as well. The JavaScript validation
logic, however, only requires the arguments to be unsigned 32-bit
integers, which is a superset of non-negative (signed) 32-bit integers.
Change the JavaScript validation to match the expectation within C++.
Fixes: https://github.com/nodejs/node/issues/44570
PR-URL: https://github.com/nodejs/node/pull/44575
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
The current documentation clearly states that createCipher() and
createDecipher() should not be used with ciphers in counter mode, but
(1) this is an understatement, and (2) these functions are
(semantically) insecure for ciphers in any other supported block cipher
mode as well.
Semantic security requires IND-CPA, but a deterministic cipher with
fixed key and IV, such as those generated by these functions, does not
fulfill IND-CPA.
Are there justified use cases for createCipher() and createDecipher()?
Yes and no. The only case in which these functions can be used in a
semantically secure manner arises only when the password argument is
not actually a password but rather a random or pseudo-random sequence
that is unpredictable and that is never reused (e.g., securely derived
from a password with a proper salt). Insofar, it is possible to use
these APIs without immediately creating a vulnerability. However,
- any application that manages to fulfill this requirement should also
be able to fulfill the similar requirements of crypto.createCipheriv()
and those of crypto.createDecipheriv(), which give much more control
over key and initialization vector, and
- the MD5-based key derivation step generally does not help and might
even reduce the overall security due to its many weaknesses.
Refs: https://github.com/nodejs/node/pull/13821
Refs: https://github.com/nodejs/node/pull/19343
Refs: https://github.com/nodejs/node/pull/22089
PR-URL: https://github.com/nodejs/node/pull/44538
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Explicitly document the attribute `Script.cachedDataRejected` in a
dedicated section.
Removes the documented option `produceCachedData` and the description
of `cachedDataRejected` in `vm.runInContext`, `vm.runInNewContext`,
and `vm.runInThisContext` as the created `vm.Script` instance is not
accessible from userland in these methods.
PR-URL: https://github.com/nodejs/node/pull/44451
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Currently, DebugSymbolsTest.ReqWrapList fails on PPC64LE when Node has
been configured with Link Time Optimization (LTO) and using RHEL 8.5
and gcc:
```console
$ . /opt/rh/gcc-toolset-11/enable
$ export CC='ccache gcc'
$ export CXX='ccache g++'
$ ./configure --enable-lto
$ make -j8 cctest
...
21:52:27 [ RUN ] DebugSymbolsTest.ReqWrapList
21:52:27 ../test/cctest/test_node_postmortem_metadata.cc:203: Failure
21:52:27 Expected equality of these values:
21:52:27 expected
21:52:27 Which is: 140736537072320
21:52:27 calculated
21:52:27 Which is: 1099680328560
21:52:27 [ FAILED ] DebugSymbolsTest.ReqWrapList (43 ms)
```
After looking into this is seems that the compiler is tampering with the
`last` variable when compiling with LTO enabled. This commit suggests
adding volatile to this variable to prevent the compiler from tampering
with it.
PR-URL: https://github.com/nodejs/node/pull/44341
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
RAND_bytes() may return 0 to indicate an error, in which case the buffer
might not have been filled with random data at all. Instead of ignoring
this case, let V8 use its own entropy source. Historically, this used to
be a weak source of entropy, but V8 now implements a proper source even
on Windows. And even if V8's own entropy source turns out to be weak, it
does not matter much: V8's PRNG itself is not cryptographically secure,
so even if it is seeded from a cryptographically secure entropy source,
it does not produce cryptographically secure random numbers.
PR-URL: https://github.com/nodejs/node/pull/44493
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
We already do this in some places. This adds the digest name to
remaining uses of ERR_CRYPTO_INVALID_DIGEST except for one occurrence in
crypto_sig.cc that would require significant refactoring due to the
unusual error handling there.
PR-URL: https://github.com/nodejs/node/pull/44468
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
When a new context with a different security token is entered, or
when no context is entered, `StackTrace::CurrentStackTrace` need to
be explicitly set with flag `kExposeFramesAcrossSecurityOrigins` to
avoid crashing.
PR-URL: https://github.com/nodejs/node/pull/44398
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
`Environment::GetCurrent` may not available in the context of OOM.
Removes the cyclic `Environment::GetCurrent` and `env->isolate()`
calls to ensure both `isolate` and `env` is present if available.
However, this behavior is not guaranteed. As
`Environment::GetCurrent` didn't allocate new handles in the heap,
when a Context is entered it can still get the valid env pointer.
Removes the unstable assertion of the absence of env in the test.
PR-URL: https://github.com/nodejs/node/pull/44398
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
This flag was added back in 2013 to support postmortem debugging on
Linux but it has a pretty bad impact on performance (up to 10%) and
I don't think it's actually necessary to get meaningful stack traces.
Maybe with mdb but gdb and lldb seem to manage just fine.
Even if the flag is necessary for postmortem debugging, I don't think
it's appropriate to make performance for all users suffer for the
benefit of a fringe group.
PR-URL: https://github.com/nodejs/node/pull/44452
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
