Addon is broken if building from source using an OpenSSL version different than the one used by Node.js

[JCMais]

It causes a segmentation fault, that is, when it does build.

This has been going on for some time, it's probably the cause of many issues: #130 #136 #137 #147 #160

Starting with Node.js 10 OpenSSL symbols were included on the Node.js lib, and the OpenSSL bundled with Node.js was bumped to 1.1.0.

I'm pretty sure this is the root cause of the current problems. Looks like the addon sometimes uses those instead of the ones from the OpenSSL it's compiled with. And since the version differs (the current version of the addon on npm, 1.3.3, is using 1.0.2o), it causes a segmentation fault.

One way to fix that was by upgrading OpenSSL so the versions match, however by doing so the build started to fail on pretty much all Node.js versions. node-gyp adds the OpenSSL headers folder used by Node.js as search folders during compilation, and they take precedence over the ones supplied by our own OpenSSL.

Besides that, Node.js didn't exported all OpenSSL symbols, just a subset of them, I've made this PR to try to allow the export of the ones required by libssh and libcurl: nodejs/node#23344

I've opened the following issue to try to track down how to correctly solve that since, currently, I do not have that much expertise with linking problems:
nodejs/node-gyp#1559
nodejs/help#1724

While no correct solution is pointed out, looks like I found a workaround: renaming the OpenSSL include folder that node-gyp adds to the list of search paths for header files, that way the ones inside the addon own OpenSSL takes precedence.

[JCMais]

New findings added to the SO question I've asked some time ago: https://stackoverflow.com/questions/52672253/how-to-compile-node-js-native-addon-against-own-openssl-library

I will probably work on what I mentioned above. Using a different OpenSSL version for each Node.js version.

This will be done only on Unix tho, doing that for Windows would be too costly right now. Besides that I got the build to work on Windows using Node.js 10 by upgrading the OpenSSL version to 1.1.0.

[Not4me]

Hey. I have no problems on Windows...

1. Compile openssl 1.1.1b with some custom algorithm (libcrypto-1.1.dll and libcrypto.lib).
2. Compile library using own algorithms that are called from openssl (libcryptowrap.dll and libcryptowrap.lib) Used functions: EVP_get_digestbyname, EVP_DigestInit, EVP_DigestUpdate, EVP_DigestFinal with custom algorithm included in openssl.
3. Install NodeJS (any)
4. Compile nodejs addon with library libcryptowrap.lib
5. Copy cryptowrap.addon, libcryptowrap.dll, libcrypto-1.1.dll. Create a file to call a function from the addon.

var addon = require('./cryptowrap');
exports.CreateDigest = (algorithm, data) => {  return addon.CreateDigest(algorithm, data) };

5. Call functions

var crypt = require('./callFunc.js');
console.log(crypt .CreateDigest('bash256', Buffer.from('')));

Work fine nodejs 11.13.0, 10.15.3, 10.4.0, 8.15.0
NodeJS call cryptowrap.node -> libcryptowrap.dll -> libcrypto_1.1.dll

But only on Windows...

On Linux algorithm not found. NodeJS use own openssl and I can't win yet......
NodeJS call cryptowrap.node -> libcryptowrap.dll ->!! own openssl.

What can i do? Compile openssl with --shared_openssl?

[JCMais]

@Not4me can you post that as an issue on https://github.com/nodejs/help?

Since it's not related to this module in particular, if you want you can also post on the issue I created there, it's on the original issue above

[JCMais]

This is fixed on develop branch and on node-libcurl@next, closing as of now.

A bump to v2 is coming the next weeks

[jinfeihan57]

@JCMais Great Work. I have encountered similar problems. Can you explain your solution in detail? Is there any PR to solve this problem? How can I solve the problem of duplication between the symbols in the node and the symbols in the library I introduced?

[JCMais]

The solution is more of a workaround, basically, you need to make sure you are always building the same version of OpenSSL than the one used by Node.js. You will introduce duplicated symbols, but they will not cause segmentation faults, as they are the same.

[jinfeihan57]

This can solve the problem, Thanks. but some third-party librarys that node depend on are very common. I think the best solution is to introduce these libraries into node in the form of dynamic libraries.