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).

[flavorjones]

@rvagg I understand what you're saying, but I was trying to address @jasnell's comment about being "very good overall at getting security updates out". Since this is the first Node 4 release, I can only assume he was referring to v0.10 and v0.12 release cycles. Perhaps he'll clarify what he meant?

@jasnell It's pretty clear that the Node team is set in this decision. All I'm trying to do is take this opportunity to make clear to the Node team what the impact of this decision is, which is namely causing more work for anyone who wants to securely deploy Node 4 on any of the most common LTS Linux distros in use today.

[tjstansell]

For folks who compile their own node package, requiring openssl 1.0.2 is fairly inconvenient. Especially considering there is still over a year left for openssl 1.0.1 support and the wide use of 1.0.1. Since 1.0.1 and 1.0.2 are supposed to be binary-compatible releases, as long as you don't use 1.0.2-specific features, then folks could use either 1.0.1 or 1.0.2 and both would work with node. When 1.0.1 is no longer the primary version for most distros, you could deprecate 1.0.1 support for node and I'm sure everyone would understand. Maybe I'm just annoyed because this is the first thing that we compile that actually requires openssl 1.0.2.

[joecool1029]

This breaks building against libressl as well with the same errors.

[jnardone]

This is a deal-breaker for us as well. We are required to link dynamically to whatever our platform version of OpenSSL is (which is used by a large number of other components) and that will likely be 1.0.1-based for at least another year. Requiring 1.0.2. features is a poor decision for adoption by any enterprise customers. Anyone based on CentOS will be unable to dynamically link (still on 1.0.1e, even for CentOS 7).

[jasnell]

Given the comments, I'm going to re-open this and queue it up for @nodejs/tsc discussion. The decision to stay with 1.0.2 is most likely to stand but it's at least worth additional discussion by the core team.

[flavorjones]

@jasnell Thanks very much for reopening the discussion!

[bnoordhuis]

@jasnell What do you want to discuss? The likelihood of downgrading to 1.0.1 is nil.

[Fishrock123]

@jasnell is this for discussion for us downgrading, or for linking an older version?

[jnardone]

Is the list of 1.0.2-specific methods significant? I'd be curious as to the impact of addressing the delta to make this API-compatible with 1.0.1.

[jasnell]

The discussion is: Is it possible to allow a custom build to dynamic link against 1.0.1 without downgrading in the core / default build. Personally, I'm -1 but given the feedback, it's worth opening up to TSC discussion and decision.

[indutny]

@jasnell it will be pretty hard to do, if possible at all.

[jasnell]

;-)... @indutny indeed... there's a very good reason I'm -1 on it lol

[jnardone]

What is the last version of Node.JS that is API-compatible with 1.0.1?