Repository navigation
Native modules ABI compatibility problems on Node 17 with OpenSSL 3 / OpenSSL 1 #41410
Description
Activity
Distros choosing to link against a different version of OpenSSL is not a new issue and has previously come up before. The solution was for the distros to request/reserve a different ABI number for the variant, e.g.
node/doc/abi_version_registry.json
Line 42 in 55ceaec
(see nodejs/TSC#621 for the previous discussion on the topic).Reacted by Momtchil Momtchev@richardlau that's a good reference but with Node-API the addon is not necessarily tied to a specific ABI number at least in the checks done automatically. If there are differences required in terms of building/running the add-on would need to handle building with both.
I believe it may be a common case where distros ( I know RH does this as well) continue to use an older OpenSSL on older versions of the OS.
@mmomtchev OpenSSL 3 claims to be compatible with openssl 1.1.1, where there specific issues that you ran into?
Yes,
SSL_CTX_load_verify_fileis present only in OpenSSL 3.3, it is used bylibcurlwhich detects OpenSSL 3.3 during the build and the module won't run with 1.1@mhdawson, I confirm OpenSSL is to be built with
OPENSSL_API_COMPAT=0x10100001Land noOPENSSL_CONFIGURED_APIorOPENSSL_MIN_API, this eliminates the depenency onSSL_CTX_load_verify_fileIn this case the ABI is preserved between OpenSSL 3.0 and OpenSSL 1.1
I will update the other issue as well
Look at this:
https://github.com/curl/curl/blob/eeca818b1e8d1e61c2d4d833aed56ce4c510a9d4/lib/vtls/openssl.c#L3100No matter what we do, this won't work on OpenSSL 1.1 if it is compiled on OpenSSL 3.0
This is the real problem@danbev, do you think that it would be possible to build the native addons with the OpenSSL 1.1 headers and to link against both OpenSSL 3.0 and OpenSSL 1.1 at runtime?
Or maybe use the 3.0 headers and patch them so they pretend to be 1.1
- added a commit that references this issue
on Jan 13, 2022 No matter what we do, this won't work on OpenSSL 1.1 if it is compiled on OpenSSL 3.0
For the reverse if you compile on OpenSSL 1.1.1 (ie earlier version of Node.js) will it then run with the later version of Node.js that uses OpenSSL 3.0?
We talked a bit about this in the Node-API team meeting and we don't promise ABI safety if you use APIs outside Node-API (like openSSL) but agreed it would be valuable to have a clear understanding of what will/will not work.
As far as I understand the OpenSSL 3.0 project goals - yes - they are supposed to guarantee this - and it does work for me so far
Reacted by Michael DawsonClosing as this is to be considered expected
Version
17.3.0
Platform
ArchLinux
Subsystem
node-addon-api
What steps will reproduce the bug?
The ArchLinux developers have decided to distribute Node.js 17 built against a shared OpenSSL 1.1.1m library.
Is this to be considered a supported configuration?
Because it has lots of implications for native modules which won't be compatible between different distributions.
Should a flag be added to the Node API version?
How often does it reproduce? Is there a required condition?
No response
What is the expected behavior?
Binary compatibility for native modules built using the same ABI level
What do you see instead?
Additional information
(https://bugs.archlinux.org/task/73268?string=node&project=0&search_name=&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=)