Compiling node v4.0.0 with OpenSSL 1.0.1 fails

[jtarchie]

We are trying to dynamically link OpenSSL with nodejs. We've done this with previous versions of the v0.12.x with no problems. With v4.0.0 we get a very long compilation error:

$ ./configure --shared-openssl
$ make
# ...
g++ -pthread -rdynamic -m64  -o /tmp/node-v4.0.0/out/Release/cctest -Wl,--start-group /tmp/node-v4.0.0/out/Release/obj.target/cctest/test/cctest/util.o /tmp/node-v4.0.0/out/Release/obj.target/deps/gtest/libgtest.a /tmp/node-v4.0.0/out/Release/obj.target/deps/v8/tools/gyp/libv8_libplatform.a /tmp/node-v4.0.0/out/Release/obj.target/deps/v8/tools/gyp/libv8_base.a /tmp/node-v4.0.0/out/Release/obj.target/deps/v8/tools/gyp/libv8_libbase.a /tmp/node-v4.0.0/out/Release/obj.target/deps/v8/tools/gyp/libv8_nosnapshot.a -Wl,--end-group -lssl -lcrypto -ldl -lrt
../src/node_crypto.cc: In function 'int node::crypto::SSL_CTX_use_certificate_chain(SSL_CTX*, BIO*, X509**, X509**)':
../src/node_crypto.cc:556:42: error: 'SSL_CTX_add1_chain_cert' was not declared in this scope
       r = SSL_CTX_add1_chain_cert(ctx, ca);
                                          ^
../src/node_crypto.cc: In static member function 'static void node::crypto::SSLWrap<Base>::CertCbDone(const v8::FunctionCallbackInfo<v8::Value>&)':
../src/node_crypto.cc:2094:51: error: there are no arguments to 'SSL_CTX_get0_certificate' that depend on a template parameter, so a declaration of 'SSL_CTX_get0_certificate' must be available [-fpermissive]
     X509* x509 = SSL_CTX_get0_certificate(sc->ctx_);
                                                   ^
../src/node_crypto.cc:2094:51: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
../src/node_crypto.cc:2095:54: error: there are no arguments to 'SSL_CTX_get0_privatekey' that depend on a template parameter, so a declaration of 'SSL_CTX_get0_privatekey' must be available [-fpermissive]
     EVP_PKEY* pkey = SSL_CTX_get0_privatekey(sc->ctx_);
                                                      ^
../src/node_crypto.cc:2098:51: error: there are no arguments to 'SSL_CTX_get0_chain_certs' that depend on a template parameter, so a declaration of 'SSL_CTX_get0_chain_certs' must be available [-fpermissive]
     rv = SSL_CTX_get0_chain_certs(sc->ctx_, &chain);
                                                   ^
../src/node_crypto.cc: In function 'int node::crypto::VerifyCallback(int, X509_STORE_CTX*)':
../src/node_crypto.cc:2423:24: error: 'SSL_is_server' was not declared in this scope
   if (SSL_is_server(ssl))
                        ^
../src/node_crypto.cc: In static member function 'static void node::crypto::Connection::New(const v8::FunctionCallbackInfo<v8::Value>&)':
../src/node_crypto.cc:2505:73: error: 'SSL_set_cert_cb' was not declared in this scope
   SSL_set_cert_cb(conn->ssl_, SSLWrap<Connection>::SSLCertCallback, conn);
                                                                         ^
../src/node_crypto.cc: In instantiation of 'static void node::crypto::SSLWrap<Base>::CertCbDone(const v8::FunctionCallbackInfo<v8::Value>&) [with Base = node::TLSWrap]':
../src/node_crypto.cc:135:16:   required from here
../src/node_crypto.cc:2094:51: error: 'SSL_CTX_get0_certificate' was not declared in this scope
     X509* x509 = SSL_CTX_get0_certificate(sc->ctx_);
                                                   ^
../src/node_crypto.cc:2095:54: error: 'SSL_CTX_get0_privatekey' was not declared in this scope
     EVP_PKEY* pkey = SSL_CTX_get0_privatekey(sc->ctx_);
                                                      ^
../src/node_crypto.cc:2098:51: error: 'SSL_CTX_get0_chain_certs' was not declared in this scope
     rv = SSL_CTX_get0_chain_certs(sc->ctx_, &chain);
                                                   ^
../src/node_crypto.cc:2104:41: error: 'SSL_set1_chain' was not declared in this scope
       rv = SSL_set1_chain(w->ssl_, chain);
                                         ^
../src/node_crypto.cc: In instantiation of 'static void node::crypto::SSLWrap<Base>::CertCbDone(const v8::FunctionCallbackInfo<v8::Value>&) [with Base = node::crypto::Connection]':
../src/node_crypto.cc:1129:3:   required from 'static void node::crypto::SSLWrap<Base>::AddMethods(node::Environment*, v8::Local<v8::FunctionTemplate>) [with Base = node::crypto::Connection]'
../src/node_crypto.cc:2335:24:   required from here
../src/node_crypto.cc:2094:51: error: 'SSL_CTX_get0_certificate' was not declared in this scope
     X509* x509 = SSL_CTX_get0_certificate(sc->ctx_);
                                                   ^
../src/node_crypto.cc:2095:54: error: 'SSL_CTX_get0_privatekey' was not declared in this scope
     EVP_PKEY* pkey = SSL_CTX_get0_privatekey(sc->ctx_);
                                                      ^
../src/node_crypto.cc:2098:51: error: 'SSL_CTX_get0_chain_certs' was not declared in this scope
     rv = SSL_CTX_get0_chain_certs(sc->ctx_, &chain);
                                                   ^
../src/node_crypto.cc:2104:41: error: 'SSL_set1_chain' was not declared in this scope
       rv = SSL_set1_chain(w->ssl_, chain);
                                         ^
../src/tls_wrap.cc: In member function 'void node::TLSWrap::InitSSL()':
../src/tls_wrap.cc:145:64: error: 'SSL_set_cert_cb' was not declared in this scope
   SSL_set_cert_cb(ssl_, SSLWrap<TLSWrap>::SSLCertCallback, this);
                                                                ^
make[1]: *** [/tmp/node-v4.0.0/out/Release/obj.target/node/src/node_crypto.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [/tmp/node-v4.0.0/out/Release/obj.target/node/src/tls_wrap.o] Error 1
make[1]: Leaving directory `/tmp/node-v4.0.0/out'
make: *** [node] Error 2

To recreate this problem, we happen to have a docker image (cloudfoundry/cflinuxfs2) we are compiling against.

Versions:

• OpenSSL 1.0.1f 6 Jan 2014
• GCC 4.8.2

System Information:

$ cat /etc/lsb-release
at /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.3 LTS"

[christo4ferris]

Hey, @jasnell can you please help with this question/issue? Thanks!

[bnoordhuis]

OpenSSL 1.0.1f 6 Jan 2014

Your copy of openssl is too old, you need 1.0.2.

[jbergstroem]

As a guideline, look in deps/ and make sure you have the same version (or newer) if you want to build a against shared libraries.

[jbergstroem]

Closing. If you're having problems compiling against a newer version of OpenSSL (or the bundled one) feel free to reopen.

[flavorjones]

I won't argue with closing this ticket, but for posterity I'd like to state the underlying issue we're trying to solve ...

Node is, for historical reasons, statically linking in openssl. When openssl CVE fixes are announced, it's at best inconvenient and at worst dangerous to have to wait for the node team to ship a new version of Node that bumps openssl. It's better from a "patchability" perspective to be able to dynamically link against the version of openssl that's shipped with, and updated by, the user's linux distro.

For previous versions of Node, people are able to ship a "patchable" version of Node by building their own binary and dynamically linking against openssl.

In Node 4, this ability is still present, which is theoretically all someone would need to ship a patchable Node binary. However, the reality of the situation is that the most common linux distros (including Ubuntu 14.04 LTS) is still shipping with openssl 1.0.1f.

So however old 1.0.1.f is perceived to be, it's still likely the most common version of openssl in the wild, and thus the result of requiring 1.0.2 is that the vast majority of developers/operators are not easily able to build a patchable version of Node.

This hurdle is likely to slow adoption of Node 4, especially among people who are security-minded (at least from my perspective).

Thanks for reading.

[MarkKropf]

It should be noted that this is not just a Ubuntu thing. The following commonly used distros are all 1.0.1 based.

RHEL 7.1 - 1.0.1e
Ubuntu 14.04 - 1.0.1f
Fedora 22 - 1.0.1k
Amazon Linux - 1.0.1e

Not sure what value the node community is getting from being put in the critical path for all openssl cve's.

[bnoordhuis]

@MarkKropf Putting the loaded language aside, the reason for 1.0.2 is pretty simple: upstream support. From https://www.openssl.org/policies/releasestrat.html:

Version 1.0.1 will be supported until 2016-12-31.
Version 1.0.2 will be supported until 2019-12-31.

The LTS version of node v4 will be supported until mid 2018. If we'd stuck with openssl 1.0.1, we'd have a year-and-a-half support gap.

[jasnell]

I would disagree that statically linking 1.0.2 into Node is going to impact it's adoption. I understand the concern about managing updates, but the Node.js project in general has been very good overall at getting security updates out. The overlapping LTS plans for OpenSSL and Node.js v4.0.0 are a key concern here as @bnoordhuis points out. Keeping v4.0.0 at v1.0.1 just is not going to be practical given the gap that would exist.

[flavorjones]

@jasnell Thanks for weighing in. I respectfully disagree with the characterization of OpenSSL turnaround as "very good", although my experience has been limited.

When openssl 1.0.1m came out, it took nearly four days for v0.10.38 and v0.12.1 to be released. You can read nodejs/node-v0.x-archive#9433 for the timeline on this CVE response.

To be honest, enterprise security teams will expect Node CVE responses at the same time they receive Ubuntu or RHEL security notices, and that's probably not a fair expectation to set on a downstream opensource project.

[rvagg]

comparisons to v0.10 and v0.12 releases aren't so helpful here, you're basically talking to an entirely new team managing releases now with completely new processes for shipping

[jasnell]

At this point, dropping back to 1.0.1 is not going to be an option in v4.x.
Dynamic linking against v1.0.2 should still be possible, however.
On Sep 11, 2015 5:19 PM, "Rod Vagg" notifications@github.com wrote:

comparisons to v0.10 and v0.12 releases aren't so helpful here, you're
basically talking to an entirely new team managing releases now with
completely new processes for shipping

—
Reply to this email directly or view it on GitHub
#2783 (comment).