Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiling node v4.0.0 with OpenSSL 1.0.1 fails #2783

Closed
jtarchie opened this issue Sep 9, 2015 · 45 comments
Closed

Compiling node v4.0.0 with OpenSSL 1.0.1 fails #2783

jtarchie opened this issue Sep 9, 2015 · 45 comments
Labels
build Issues and PRs related to build files or the CI. openssl Issues and PRs related to the OpenSSL dependency.

Comments

@jtarchie
Copy link

jtarchie commented Sep 9, 2015

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
Copy link

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

@bnoordhuis
Copy link
Member

OpenSSL 1.0.1f 6 Jan 2014

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

@mscdex mscdex added build Issues and PRs related to build files or the CI. openssl Issues and PRs related to the OpenSSL dependency. labels Sep 9, 2015
@jbergstroem
Copy link
Member

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
Copy link
Member

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

@flavorjones
Copy link

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
Copy link

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
Copy link
Member

@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
Copy link
Member

jasnell commented Sep 11, 2015

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
Copy link

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

@jtarchie jtarchie changed the title Compiling node v4.0.0 with ./configure --shared-openssl fails. Compiling node v4.0.0 with OpenSSL 1.0.1 fails Sep 11, 2015
@rvagg
Copy link
Member

rvagg commented Sep 12, 2015

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
Copy link
Member

jasnell commented Sep 12, 2015

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
Copy link

@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
Copy link

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
Copy link

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

@jnardone
Copy link

jnardone commented Oct 6, 2015

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
Copy link
Member

jasnell commented Oct 6, 2015

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.

@jasnell jasnell reopened this Oct 6, 2015
@flavorjones
Copy link

@jasnell Thanks very much for reopening the discussion!

@bnoordhuis
Copy link
Member

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

@Fishrock123
Copy link
Contributor

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

@jnardone
Copy link

jnardone commented Oct 6, 2015

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
Copy link
Member

jasnell commented Oct 6, 2015

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
Copy link
Member

indutny commented Oct 6, 2015

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

@jasnell
Copy link
Member

jasnell commented Oct 6, 2015

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

@jnardone
Copy link

jnardone commented Oct 6, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Issues and PRs related to build files or the CI. openssl Issues and PRs related to the OpenSSL dependency.
Projects
None yet
Development

No branches or pull requests