CSPRNG implicitly casts the size_t length argument to a signed int when
calling RAND_bytes(), which leaves it up to the caller to ensure that
the length argument actually fits into such a signed int. However, not
all call sites explicitly ensure that, which could lead to subtle bugs.
In OpenSSL 3, use RAND_bytes_ex() instead, which does not require
casting the length to a signed int.
In OpenSSL 1.1.1, RAND_bytes_ex() is not supported, thus we have to
process blocks of size INT_MAX one by one.
PR-URL: https://github.com/nodejs/node/pull/47515
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
The JS layer already uses validateInt32(keylen, 'keylen', 0) to ensure
that the keylen argument fits into a signed 32-bit integer, thus, the
THROW statement in C++ is unreachable (unless the binding is accessed
directly, of course).
PR-URL: https://github.com/nodejs/node/pull/47407
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Previously the native ShadowRealm objects were never actually tracked
in the heap snapshot - the tracking starts with the Environment,
we don't call the tracking methods unless it's reachable natively from
the Environment. This patch adds a set in the Environment for tracking
shadow realms in the heap snapshot.
Drive-by: remove redundant MemoryInfo() overrides from the derived
classes of Realm and remove the tracking of `env` from
`Realm::MemoryInfo()` because the realms don't hold the Environment
alive (even for the principal realm, it's the other way around).
PR-URL: https://github.com/nodejs/node/pull/47389
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Instead of storing the function template of BaseObject for checking
if an object is BaseObject by calling HasInstance, simply checks
the first internal field of the object, which is always set in the
BaseObject constructor. This is simpler and faster
(there is now no need to iterate over the inheritance for the check).
PR-URL: https://github.com/nodejs/node/pull/47217
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
SnapshotSerializerDeserializer::GetName() appears to confuse static
analysis such as Coverity.
This changes the function structure to a sequence of if-else blocks and
marks all branch conditions as constexpr. (Unfortunately, this results
in a dangling 'else' keyword in the V macro.)
As per a request in the PR discussion, this change does _not_ ensure
that GetName<T>() can only be called for known types T and instead still
returns an empty string in that case.
Also use std::is_unsigned_v instead of !std::is_signed_v.
PR-URL: https://github.com/nodejs/node/pull/46509
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
The only bad handler value we can inhert from before exec is SIG_IGN
(any actual function pointer is reset to SIG_DFL during exec).
If that's the case, we want to reset it back to SIG_DFL.
However, it's also possible that an embeder (or an LD_PRELOAD-ed
library) has set up own signal handler for own purposes
(e.g. profiling). If that's the case, keep it intact.
Fix#47013
PR-URL: https://github.com/nodejs/node/pull/47188
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Instead of returning the internal loaders from the bootstrap script,
we can simply call a binding to store them in C++. This eliminates
the need for specializing the handling of this script.
PR-URL: https://github.com/nodejs/node/pull/47215
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
The JS layer already verifies that divisor_bits is either a non-negative
32-bit signed integer or null/undefined, in which case it passes -1 to
the C++ layer. In either case, the C++ layer receives a 32-bit signed
integer greater than or equal to -1.
PR-URL: https://github.com/nodejs/node/pull/47168
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Previously, the JS layer would validate that the value of the 'checks'
option was an unsigned 32-bit integer, otherwise throwing an appropriate
error but with a slightly misleading error message. Then the C++ layer
would validate that the value was an unsigned 31-bit integer, otherwise
throwing an appropriate error, but with a different (and even less
helpful) error message.
Instead, make the JS layer aware of the 31-bit restriction so that no
validation in C++ is necessary and so that the error message always
matches the exact requirement.
PR-URL: https://github.com/nodejs/node/pull/47165
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
None of these constants have any effect in recent OpenSSL versions, not
even in Node.js release lines that still use OpenSSL 1.1.1.
It is likely rare that these options are still used (intentionally), and
removing them is unlikely to break any existing applications. These
constants can only be passed to the secureOptions option of
tls.createSecureContext() and related APIs, and a value of undefined
will be ignored. Similarly, if a bitwise combination of multiple options
is used, undefined constants will not change the behavior because
(a | undefined | b) === (a | b) for (small) integers a and b.
Refs: https://github.com/nodejs/node/pull/46954
Refs: https://github.com/nodejs/node/pull/47066
PR-URL: https://github.com/nodejs/node/pull/47073
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Tobias Nießen