`node/openssl/ssl.h` should compile without any additional defines

[mmomtchev]

Version

17.0.1

Platform

5.11.0-38-generic #42~20.04.1-Ubuntu SMP

Subsystem

No response

What steps will reproduce the bug?

node/openssl/ssl.h is exported in the node-gyp bundle to be used by native modules that need to link against the openssl symbols in Node

Currently, when building Node.js itself some of these defines come from openssl.gyp: OPENSSL_API_COMPAT and OPENSSL_CONFIGURED_API

This means that a native addon must also define them and must do so in a manner compatible with Node.js across the eventual future versions

How often does it reproduce? Is there a required condition?

No response

What is the expected behavior?

These defines should be present somewhere in an additional include file to be added to the node-gyp bundle distribution

What do you see instead?

No response

Additional information

No response

[mhdawson]

@danbev thoughts on this?

[danbev]

@danbev thoughts on this?

I haven't looked at node-gyp at all during the OpenSSL work so if this is something that is not covered by the OpenSSL tests in test/addons (openssl-binding, openssl-client-cert-engine, or openssl-key-engine) then I've missed it I'm afraid.

I added OPENSSL_API_COMPAT to node.gypi to avoid warnings due to the usage of deprecated APIs. We could remove this and live with the warnings but since we need to keep backward compatibility with OpenSSL 1.1.1 for some time and it might become annoying seeing these.

[mmomtchev]

@danbev You should be able to include node/openssl/ssl.h from a standalone application from outside the Node.js tree

This is the test:

#include "openssl/ssl.h"

int main() {
	return 0;
}

If you have ever compiled a native module with 17.0.1 you will have this directory:

gcc -I${HOME}/.cache/node-gyp/17.0.1/include/node -o openssl openssl.c

${HOME}/Caches on macOS

Normally, the OpenSSL of node-gyp should be a drop-in replacement for a system-installed OpenSSL - it allows to build a native addon that uses OpenSSL without linking in a second copy in the Node executable - which might not work at all

[d3x0r]

On windows, and alpine linux docker image, updating to node 17...

After getting around OPENSSL_API_COMPAT by just defining it in CMakeList for it (and the binding.gyp), I ran into

  error "The requested API level higher than the configured API compatibility level" 

which OPENSSL_CONFIGURED_API is undefined... so being 0, anything I set as a compatibility level fails.

adding this to the top of ....cmake-js\node-x64\v17.0.1\include\node\openssl\macros.h

#include "./configuration.h"

(which I don't think is a good or correct solution)

But even then I had to define the OPENSSL_MIN_API=30000 in my build configuration

Edit: Sorry for being terse and vague.

After tracking down this, and getting some hints, I made forward progress... there's still missing symbols (RSA_new() and RSA_free() for examples). There's a openssl/configuration.h file which is new in 17 that was not in 16. This configuration.h is not included by anything in openssl directory, and seems the user is supposed to include this file now too?

[mscdex]

Just chiming in that I'm also seeing this with node v17.x ("OPENSSL_API_COMPAT expresses an impossible API compatibility level").

Any (official) solutions to this? /cc @nodejs/crypto

[d3x0r]

Just chiming in that I'm also seeing this with node v17.x ("OPENSSL_API_COMPAT expresses an impossible API compatibility level").

Any (official) solutions to this? /cc @nodejs/crypto

"OPENSSL_API_COMPAT=10101"

and

#if NODE_MAJOR_VERSION >= 17
#  include <openssl/configuration.h>
#endif

before including anything from OpenSSL. If configuration.h is not defined than the configured version is undefined and becomes a '0' which everything is bigger than the configured level then.

[mmomtchev]

@danbev How about including #define OPENSSL_API_COMPAT=10101 in node.h?

[danbev]

@danbev How about including #define OPENSSL_API_COMPAT=10101 in node.h?

Sorry about the late reply. I'm currently on a leave of absence and will be back working in April, and would be happy to take a closer look at this then (unless someone else beats me to it).

[mscdex]

"OPENSSL_API_COMPAT=10101"

and

#if NODE_MAJOR_VERSION >= 17
#  include <openssl/configuration.h>
#endif

before including anything from OpenSSL. If configuration.h is not defined than the configured version is undefined and becomes a '0' which everything is bigger than the configured level then.

Unfortunately that doesn't seem to work for me, I still get the same error.

[mscdex]

Looks like part of the problem in my particular case is that homebrew on macos is using OpenSSL 1.1.1 with their node v17.x formula, which causes problems for addons because of the OpenSSL 3.0 headers that get pulled in by node-gyp. The addon thinks it's compiling for OpenSSL 3.0 but then during runtime you can get various errors from dyld depending on if you are using new OpenSSL APIs or OpenSSL APIs that are now aliases in 3.0.