Unlike JS-only modules, native add-ons are always associated with a
dynamic shared object from which they are loaded. Being able to
retrieve its absolute path is important to native-only add-ons, i.e.
add-ons that are not themselves being loaded from a JS-only module
located in the same package as the native add-on itself.
Currently, the file name is obtained at environment construction time
from the JS `module.filename`. Nevertheless, the presence of `module`
is not required, because the file name could also be passed in via a
private property added onto `exports` from the `process.dlopen`
binding.
As an attempt at future-proofing, the file name is provided as a URL,
i.e. prefixed with the `file://` protocol.
Fixes: https://github.com/nodejs/node-addon-api/issues/449
PR-URL: https://github.com/nodejs/node/pull/37195
Co-authored-by: Michael Dawson <mdawson@devrus.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
This commit introduces a mutex field on the ManagedEVPPKey class
intended to be used when multiple threads require access to an OpenSSL
EVP_PKEY object. The motivation for this came from the work being done
to upgrade Node.js to OpenSSL 3.0.
OpenSSL objects, like EVP_PKEY, are not thread safe (see refs for
details). In versions prior to OpenSSL 3.0 this was not noticeable and
did not cause any issues (like incorrect logic or crashes), but with
OpenSSL 3.0 this does cause issues if access to an EVP_PKEY instance is
required from multiple threads without locking.
In OpenSSL 3.0 when the evp_pkey_downgrade function is called, which
downgrades an EVP_PKEY instance to a legacy version, it will clear all
the fields of EVP_PKEY struct except the lock (#13374). But this also
means that keymgmt and keydata will also be cleared, which other parts
of the code base depends on, and those calls will either fail to export
the key (returning null) or crash due to a segment fault.
This same code works with OpenSSL 1.1.1 without locking and I think this
is because there is no downgrade being done in OpenSSL 1.1.1. But even
so, as far as I can tell there are no guarantees that these object are
thread safe in 1.1.1 either and should be protected with a lock.
PR-URL: https://github.com/nodejs/node/pull/36825
Refs: https://github.com/openssl/openssl/pull/13374
Refs: https://github.com/openssl/openssl/pull/13374
Refs: https://github.com/openssl/openssl/issues/2165)
Refs: https://www.openssl.org/blog/blog/2017/02/21/threads
Reviewed-By: James M Snell <jasnell@gmail.com>
Great effort is taken to keep `util.inspect()` from throwing while
inspecting a linked list or other items that require recursion. It is
likely still possible at this time to cause a throw with prototype
pollution, but that will change soon when the code is modified to use
primordials.
This commit instructs our coverage to not be concerned about not being
able to reach the throwing-an-error code and changes the throw there to
an assert so users will be instructed to open a bug with Node.js should
they manage to cause the code to throw.
PR-URL: https://github.com/nodejs/node/pull/37249
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
1. Put the v8 binding data class into a header so we can reuse
the class definition during deserialization.
2. Put the v8 binding code into node::v8_utils namespace for
clarity.
3. Move the binding data property initialization into its
constructor so that we can reuse it during deserialization
4. Reorder the v8 binding initialization so that we don't
unnecessarily initialize the properties in a loop
PR-URL: https://github.com/nodejs/node/pull/37112
Refs: https://github.com/nodejs/node/pull/36943
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Previously, this was a per-class string constant for BindingData
which is used as keys for identifying these objects in the binding
data map. These are just type names of the BindingData.
This patch renames the variable to type_name so that
we can generalize this constant for other BaseObjects and use
it for debugging and logging the types of other BaseObjects.
PR-URL: https://github.com/nodejs/node/pull/37112
Refs: https://github.com/nodejs/node/pull/36943
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Add more context around the TODO change required for achieving the
task. When destructuring the isolate and environment_vars from the
environment object, it is leading to recursive dependency and thus not
able to refactor it in a better way.
PR-URL: https://github.com/nodejs/node/pull/37140
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Pooja D P <Pooja.D.P@ibm.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Using the reset does a double allocation and is error prone if some
exception occured which is very unlikely but can happen. make_shared_ptr
gives hedge over this and handle the failure in allocation.
PR-URL: https://github.com/nodejs/node/pull/37139
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This patch
1. Refactors the bootstrap routine of the main instance so that
when --no-node-snapshot is used,
Environment::InitializeMainContext() will only be called once
(previously it would be called twice, which was harmless for now
but not ideal).
2. Mark the number of BaseObjects in RunBootstrapping() when creating
the Environment from scratch and in InitializeMainContext() when
the Environment is deserialized. Previously the marking was done in
the Environment constructor and InitializeMainContext() respectively
for the cctest which was incorrect because the cctest never uses
an Environment that's not bootstrapped. Also renames the mark
to base_object_created_after_bootstrap to reflect what it's
intended for.
PR-URL: https://github.com/nodejs/node/pull/37113
Refs: https://github.com/nodejs/node/pull/36943
Reviewed-By: James M Snell <jasnell@gmail.com>
Benjamin Gruenbaum