<div dir="ltr">Forwarded: <a href="https://github.com/nodejs/node/issues/21897">https://github.com/nodejs/node/issues/21897</a><br><div class="gmail_extra"><br><div class="gmail_quote">2018-07-22 17:37 GMT+02:00 Elana Hashman <span dir="ltr"><<a href="mailto:ehashman@debian.org" target="_blank">ehashman@debian.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Package: nodejs<br>
Version: 8.10.0~dfsg-2<br>
Severity: important<br>
<br>
This bug was initially reported downstream against Ubuntu in <a href="https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863" rel="noreferrer" target="_blank">https://bugs.launchpad.net/ubu<wbr>ntu/+source/nodejs/+bug/177986<wbr>3</a> by the upstream GRPC maintainer.<br>
<br>
Summary of the issue: upstream nodejs vendors its openssl dependency and exports the openssl symbols as part of its ABI for native extensions. Node 8.x depends on openssl 1.0.2. However, Node 8.x in Debian depends on the default openssl, version 1.1.0. As a result, the Debian nodejs package provides an incompatible ABI for compiled native node extensions, resulting in subtle and confusing bugs for end users.<br>
<br>
Note that Ubuntu is using an unpatched upstream Debian package in Bionic/18.04. Hence, this bug really affects the Debian build, not just Ubuntu. IMO we should not diverge from the ABI contract that upstream provides. Typical nodejs development practices involve downloading dependencies with npm, which may include precompiled native dependencies that rely on a stable node ABI. It is very confusing for end users to install a system nodejs, download these deps as normal, and then encounter subtle incompatibilities with scary error messages, like this:<br>
<br>
node: symbol lookup error: /home/pixel/node-openssl-addon<wbr>-example/build/Release/openssl<wbr>_example.node: undefined symbol: SSL_library_init<br>
<br>
This seriously impacts the user experience for nodejs users. And I'm worried that because this is an openssl 1.0.x issue, this problem is even uglier. I imagine nodejs vendored upstream openssl, which lacks symbol versions altogether (which could potentially mitigate the issue a little bit, for systems that have both openssl version .so's installed).<br></blockquote><div><br></div><div>I agree there is a problem. I disagree the problem is only on the distributor side.</div><div>The bug is reported upstream (see forwarded url above).</div><div>Complaining that the distributor is not doing the right thing is a wrong approach to the problem.</div><div>You should instead try to understand more deeply the situation and see what other languages do about that.</div><div><br></div><div>TLDR; the pratical solution is to promote compilation of addons - which is *straightforward* on debian/ubuntu/fedora and derivatives</div><div>(you just need to explain which development packages must be installed).</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Ubuntu Bionic will need to patch their builddeps downstream to use the right version of openssl, and I'm going to comment on their bug along those lines. This is also an option for us in Debian, but given that we want to drop openssl 1.0.2 in buster, I'd suggest we could also fix this bug by upgrading node to 10.x, available in experimental, which depends on openssl 1.1.0 upstream.</blockquote><div><br></div><div>Agreed ! As the main nodejs maintainer the only reason it is not already the case is because i did not have time to handle it.</div><div>I do that on free time, and it's a rare thing these days...</div><div><br></div><div>Jérémy</div><div><br></div></div></div></div>