Node: 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 https://github.com/nodejs/node-v0.x-archive/issues/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" [email protected] 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
https://github.com/nodejs/node/issues/2783#issuecomment-139691458.

[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?

[jtarchie]

@jnardone From our logs, 0.12.7, which we currently dynamically link to 1.0.1f.

[evanlucas]

https://github.com/nodejs/node/commit/e4872d7405c60da50692e3c4cd5a9df2e96a5680 looks to be the commit that introduced 1.0.2

[Fishrock123]

I believe OpenSSL 1.0.2 was one of the breaking changes landed in 2.0.0

On Oct 6, 2015, at 10:50 AM, Evan Lucas [email protected] wrote:

e4872d7 looks to be the commit that introduced 1.0.2

—
Reply to this email directly or view it on GitHub.

[jasnell]

So just to document what would actually need to happen here: in order for Node v4.x to compile against a linked 1.0.1, someone would essentially need to implement some kind of compatible shim. Reverting the changes that were made in core to move up to 1.0.2 is not going to be possible or desirable at this point. While I still want to leave this open for consideration on tomorrows TSC call, I do not see a path forward unless someone steps up willing to work on real code.

[shigeki]

I've just greped Node-4.x sources with only new API symbols of 1.0.2 without including new members and constants, and found the following 4 APIs are introduced.

node_crypto.cc: X509* x509 = SSL_CTX_get0_certificate(sc->ctx_);
node_crypto.cc: EVP_PKEY* pkey = SSL_CTX_get0_privatekey(sc->ctx_);
node_crypto.cc: if (SSL_is_server(ssl))
node_crypto.cc: SSL_set_cert_cb(conn->ssl_, SSLWrap::SSLCertCallback, conn);
node_crypto.h: // SSL_set_cert_cb
tls_wrap.cc: SSL_set_cert_cb(ssl_, SSLWrap::SSLCertCallback, this);

We've already moved to use SSL_set_cert_cb for SNI and OCSP callbacks so I think it is hard to make changes to have a compatibility with 1.0.1.

[rvagg]

From the TSC meeting(s) the general consensus goes something like this:

+Conclusion was that this would be difficult and would result in a build that had some features disabled. The TSC is not going to undertake this work and would have reservations officially supporting a build that cripples some crypto features. However, pull requests for this work are welcome and would be considered.

Additional concerns, including the OpenSSL LTS lifecycle are mentioned by multiple parties in this thread already.

I don't mind this thread staying open to capture future discussion, and possibly work, on this area.

[jelmd]

FWIW: I got v5.0.0 compiled on Solaris 11.3, which is dyn linked against the FIPS capable OpenSSL lib 1.0.1p (see ssl*.patch on http://iws.cs.uni-magdeburg.de/~elkner/tmp/node5/). The only real bad HACK is the "backport" of the SSL_get_server_tmp_key() fn, since CERT_PKEY is per default hidden and 1.0.1 specific, i.e. has different layout and size in other versions like 1.0.2. Anyway, all tests succeed except test-tls-ocsp-callback, test-tls-sni-option and test-tls-sni-server-client - I doubt, that these are a porting issue, but who cares - I can live with it for now ;-)

[bnoordhuis]

I'm going to close out this issue. There hasn't been any activity in the last six months so I'm assuming this is either resolved, obsolete or it wasn't that important after all. It's quite possibly the latter because no one followed up with pull requests, as far as I'm aware.

[flavorjones]

@bnoordhuis That's an unfair assumption to make. It was made pretty clear to us via personal communications that PRs wouldn't be accepted, as there was no consensus that this support was desirable. And that's fine, we dealt with the community decision and moved on with our lives.

You could have just left it at "There hasn't been any activity."

[jasnell]

@flavorjones ... sorry for the confusion.

[cschug]

Would be great to drop a note in BUILDING.md regarding version requirements on optional system software components like OpenSSL.

[jbergstroem]

@cshug: the optional shared dependencies follows the same versions you can find in deps/. Just have a look in that folder for your corresponding release!

[jelmd]

FWIW: patch update wrt 6.x - http://iks.cs.ovgu.de/~elkner/tmp/node6/

[UnitedMarsupials-zz]

@jelmd, thank you for posting the link to patches, which allow NodeJS to build against older OpenSSL. Unfortunately, node-7.4.0, when built this way, crashes in many different self-tests... Any chance for an update? More specifically, the crashes all appear to be due to the following double-free:
==8267== Invalid free() / delete / delete[] / realloc() ==8267== at 0x4C24DDB: free (in /opt/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==8267== by 0x55E4184: CRYPTO_free (in /lib/libcrypto.so.7) ==8267== by 0x5893475: SSL_CTX_free (in /usr/lib/libssl.so.7) ==8267== by 0x1E78650: node::crypto::SecureContext::FreeCTXMem() (node_crypto.h:156) ==8267== by 0x1E4B4B7: node::crypto::SecureContext::Close(v8::FunctionCallbackInfo<v8::Value> const&) (node_crypto.cc:1113) ==8267== by 0xB4F8ED: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (api-arguments.cc:21) ==8267== by 0xC32EDC: v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) (builtins-api.cc:106) ==8267== by 0xC3079E: v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) (builtins-api.cc:135) ==8267== by 0xC2FF55: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (builtins-api.cc:123) ==8267== by 0x8B063A6: ??? ==8267== by 0x8B82489: ??? ==8267== by 0x8B4A7C2: ??? ==8267== Address 0x2a35d120 is 0 bytes inside a block of size 144 free'd ==8267== at 0x4C24DDB: free (in /opt/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==8267== by 0x55E4184: CRYPTO_free (in /lib/libcrypto.so.7) ==8267== by 0x5893475: SSL_CTX_free (in /usr/lib/libssl.so.7) ==8267== by 0x1E78650: node::crypto::SecureContext::FreeCTXMem() (node_crypto.h:156) ==8267== by 0x1E4B4B7: node::crypto::SecureContext::Close(v8::FunctionCallbackInfo<v8::Value> const&) (node_crypto.cc:1113) ==8267== by 0xB4F8ED: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (api-arguments.cc:21) ==8267== by 0xC32EDC: v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) (builtins-api.cc:106) ==8267== by 0xC3079E: v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) (builtins-api.cc:135) ==8267== by 0xC2FF55: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (builtins-api.cc:123) ==8267== by 0x8B063A6: ??? ==8267== by 0x8B82489: ??? ==8267== by 0x8B4A7C2: ???

the reason for 1.0.2 is pretty simple: upstream support

@bnoordhuis, that may be a reason to use 1.0.2, but it is not a reason to abandon compatibility with the older release and use API-calls absent in 1.0.1. In addition to the already substantial list of Linux-distributions, which still bundle OpenSSL-1.0.1, add FreeBSD... The shared OpenSSL mode of compilation should be the default, and it should be possible to use version 1.0.1 of it (even if that would sacrifice some functionality).

[gibfahn]

@UnitedMarsupials isn't 1.0.1 out of support (https://www.openssl.org/policies/releasestrat.html)? If so linking to something that no longer gets security fixes is perhaps not a good idea.

[flavorjones]

@gibfahn Ubuntu Trusty 14.04 ships with openssl 1.0.1f, which will be supported by Canonical until April 2019. Canonical will presumably backport security fixes to 1.0.1 until then.

So, while it may be out of support from an upstream perspective, it seems as though some distros are taking on the support responsibility.

[UnitedMarsupials-zz]

@gibfahn, whether it is supported by the OpenSSL team (as much as such support even _matters_ in open source), is irrelevant. What is relevant is that the majority of the mainstream operating systems' _current_ versions still include the older version. RedHat/CentOS-7, FreeBSD-10 to name two.

Now, statically linking with OpenSSL is not only wasteful (of both diskspace and run-time RAM -- the most precious resource), but also less secure. To fix a future bug, updating my OpenSSL libraries will not be enough, I'll need to update node _separately_.

As long as OpenSSL-1.0.1 remains in wide use, applications using the API should be able to use the older version, #ifdef-ing some latest features, if necessary.

I, once again, urge node-developers to switch to using the already-installed versions of all of the deps/ libraries by default and even stop bundling your own versions of them. You aren't as bad as OpenOffice -- which includes its own copy of Python (!) and an entire kitchen-sink of other 3rd-party libraries -- but you are close...

[jelmd]

@UnitedMarsupials "Unfortunately" ;-) my primary target (Solaris 11) ships openssl 1.0.2 since 11.3 SRU 14.6 (November 2016) and thus there is no need => no time to maintain the 1.0.2 related patches (i.e. ssl*.patch). Never tested any version < 5.0.0 || > 6.3.1 with it. So yes, it may fail on other versions or not even align with the openssl packages shipped by your OS vendor. E.g. I know, that RedHat often ports back features of "next releases" and thus the system/openssl util might say it is 1.0.1, but already provides features from 1.0.2 (e.g. SSL_get_server_tmp_key()). Perhaps Canonical or other vendors do similar things. In this case it is probably the best to check the vendor patches for the related packages/do a readelf -s $lib and if it looks promising, adjust the node build system to accept 1.0.1 (not sure, if there is an explicit version number check) and try, how far it goes ...

So FWIW: My patch set for 6.9.1 got reduced to http://iks.cs.ovgu.de/~elkner/tmp/node6-1.0.2/

And yes - I agree, static linking is evil for several reasons, but on the other side a "quick and dirty" workaround/"promotion help" as long as OS distributions haven't caught up (even the latest Ubuntu still ships 0.12?) ...

[gibfahn]

@jelmd Ubuntu 16.04 is v4.2.6 for me.

[jelmd]

Ah ok - thanx!

[UnitedMarsupials-zz]

@jelmd, yes, the OSes are moving to upgrade their OpenSSL pieces, but slowly -- RedHat, which is what I'm saddled with at work, still has 1.0.1 in their current version 7. FreeBSD -- which is what I use at home -- includes 1.0.2, but only in version 11, which is meant for "early adopters". The mainstream FreeBSD-10 still contains OpenSSL-1.0.1.

Now, my debugging of the double-free posted above shows, that the block being freed is a root certificate store, which is somehow referenced by two different context-structures. Says valgrind:
==21950== Block was alloc'd at ==21950== at 0x4C2469F: malloc (in /opt/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==21950== by 0x55E3DF7: CRYPTO_malloc (in /lib/libcrypto.so.7) ==21950== by 0x555F84B: X509_STORE_new (in /lib/libcrypto.so.7) ==21950== by 0x1E4DC53: node::crypto::NewRootCertStore() (node_crypto.cc:807) ==21950== by 0x1E48F02: node::crypto::SecureContext::AddRootCerts(v8::FunctionCallbackInfo<v8::Value> const&) (node_crypto.cc:930) ==21950== by 0xB4F8ED: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (api-arguments.cc:21) ==21950== by 0xC32EDC: v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) (builtins-api.cc:106)
Could it be, your patches simply forget to up a ref-count somewhere?