| 2018-07-03 13:06:31 |
Nicolas Noble |
bug |
|
|
added bug |
| 2018-07-19 20:48:14 |
David Coronel |
bug |
|
|
added subscriber David Coronel |
| 2018-07-19 21:02:18 |
Dan Streetman |
bug |
|
|
added subscriber Dan Streetman |
| 2018-07-20 10:46:00 |
Dominique Poulain |
bug |
|
|
added subscriber Dominique Poulain |
| 2018-07-20 22:17:43 |
Nicolas Noble |
bug watch added |
|
https://github.com/nodejs/node/issues/21897 |
|
| 2018-07-22 15:48:12 |
Elana Hashman |
bug |
|
|
added subscriber Elana Hashman |
| 2018-07-22 15:50:24 |
Elana Hashman |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904274 |
|
| 2018-07-23 18:27:57 |
Dan Streetman |
bug task added |
|
nodejs (Debian) |
|
| 2018-07-23 18:34:55 |
Bug Watch Updater |
nodejs (Debian): status |
Unknown |
New |
|
| 2018-07-23 21:21:47 |
Dan Streetman |
nominated for series |
|
Ubuntu Cosmic |
|
| 2018-07-23 21:21:47 |
Dan Streetman |
bug task added |
|
nodejs (Ubuntu Cosmic) |
|
| 2018-07-23 21:21:47 |
Dan Streetman |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-07-23 21:21:47 |
Dan Streetman |
bug task added |
|
nodejs (Ubuntu Bionic) |
|
| 2018-07-23 21:21:47 |
Dan Streetman |
nominated for series |
|
Ubuntu Trusty |
|
| 2018-07-23 21:21:47 |
Dan Streetman |
bug task added |
|
nodejs (Ubuntu Trusty) |
|
| 2018-07-23 21:21:47 |
Dan Streetman |
nominated for series |
|
Ubuntu Xenial |
|
| 2018-07-23 21:21:47 |
Dan Streetman |
bug task added |
|
nodejs (Ubuntu Xenial) |
|
| 2018-07-23 21:22:02 |
Dan Streetman |
nodejs (Ubuntu Trusty): status |
New |
Invalid |
|
| 2018-07-23 21:22:05 |
Dan Streetman |
nodejs (Ubuntu Xenial): status |
New |
Invalid |
|
| 2018-07-23 21:22:09 |
Dan Streetman |
nodejs (Ubuntu Bionic): status |
New |
In Progress |
|
| 2018-07-23 21:22:14 |
Dan Streetman |
nodejs (Ubuntu Cosmic): status |
New |
In Progress |
|
| 2018-07-23 21:22:20 |
Dan Streetman |
nodejs (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2018-07-23 21:22:22 |
Dan Streetman |
nodejs (Ubuntu Cosmic): importance |
Undecided |
Medium |
|
| 2018-07-23 21:24:44 |
Dan Streetman |
nodejs (Ubuntu Bionic): assignee |
|
Dan Streetman (ddstreet) |
|
| 2018-07-23 21:24:46 |
Dan Streetman |
nodejs (Ubuntu Cosmic): assignee |
|
Dan Streetman (ddstreet) |
|
| 2018-07-25 12:38:22 |
Dan Streetman |
bug |
|
|
added subscriber kapouer |
| 2018-07-25 12:47:07 |
Dan Streetman |
bug |
|
|
added subscriber Ubuntu Security Team |
| 2018-07-25 12:52:36 |
Dan Streetman |
attachment added |
|
lp1779863-bionic.debdiff https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863/+attachment/5167616/+files/lp1779863-bionic.debdiff |
|
| 2018-07-25 12:52:51 |
Dan Streetman |
tags |
amd64 apport-bug bionic |
amd64 apport-bug bionic sts-sponsor-ddstreet |
|
| 2018-07-25 13:03:27 |
Dan Streetman |
description |
Background:
NodeJS has a native extension API: https://nodejs.org/api/addons.html
It's fairly understood by developers that NodeJS's ABI is stable, and that one module built using a version of nodejs should work on another semantically version compatible of nodejs.
NodeJS exposes various third party libraries to the native module developers. Quote from the addons developers page: "Node.js includes a number of other statically linked libraries including OpenSSL. These other libraries are located in the deps/ directory in the Node.js source tree. Only the libuv,i OpenSSL, V8 and zlib symbols are purposefully re-exported by Node.js and may be used to various extents by Addons."
It's fairly understood by developers that native modules have the same ABI guarantee than the rest of the node API.
The NodeJS ecosystem uses native modules extensively, and it's fairly common for developers to publish precompiled versions of their extensions so that the typical end-user can simply npm install their dependencies without worrying about having a compiler installed. Some packages will do their own thing (see for instance https://www.npmjs.com/package/uws), while others will rely on third party extensions to facilitate their work. See for instance prebuild (https://www.npmjs.com/package/prebuild) that has a handful of dependents, or node-pre-gyp (https://www.npmjs.com/package/node-pre-gyp) that has north of 350 dependents. So the nodejs ecosystem has roughly 400 native packages that are publishing prebuilt versions of their extensions.
Problem with the Ubuntu nodejs package:
Put simply, it breaks prebuilt packages that depend on OpenSSL. NodeJS 8.10.0 officially comes with OpenSSL 1.0.2n, while the NodeJS 8.10.0 that comes with the Ubuntu package exposes OpenSSL 1.1.0g.
Since there are ABI breakages between OpenSSL 1.0.2 and 1.1.0, these ABI breakages are bubbling up to any prebuilt native addon.
Here is an example:
https://github.com/nicolasnoble/openssl-nodejs-ubuntu-demo
If you build this package under the mainline nodejs, it will try to import the following symbols from OpenSSL 1.0.2:
. SSL_library_init
. SSLeay_version
Whereas if you build it under Ubuntu's nodejs, it will try to import the following symbols instead from OpenSSL 1.1.0:
. OPENSSL_init_ssl
. OpenSSL_version
Therefore, trying to load one prebuilt module from one version of the runtime to another will result in a symbol loading error:
node: symbol lookup error: /home/pixel/node-openssl-addon-example/build/Release/openssl_example.node: undefined symbol: SSL_library_init
Incidentally, nodejs 10.5.0 uses OpenSSL 1.1.0h, and compiling the same demo module with this version of node will try to import the proper symbols. Obviously, since the module will be built for the wrong version of the nodejs runtime, it won't load, but the SSL symbols are now proper.
This creates weird bug reports for nodejs extension developers, such as https://github.com/grpc/grpc-node/issues/341
Another example is uws. Trying to use uws in ubuntu's nodejs will result in the same sort of failures. Which means there are at least two packages available out there that are affected by this issue.
I don't think this is easily solvable, and all of my suggestions for fixing it have severe cons. Ubuntu won't want to downgrade their system's OpenSSL for this. Maybe there's a way to get another openssl package for 1.0.2, and have the nodejs runtime for Ubuntu depend on it. Another possible solution would be to radically upgrade nodejs to 10, so that the ABI of OpenSSL will then match properly. But this may be viewed as a too radical upgrade.
One sort of mitigation option would be to get node-pre-gyp and prebuild to recognize that it's running with this version of the nodejs runtime, so that it can recognize and take actions, such as downloading an ubuntu-specific version of the prebuilt extension, or recompiling from sources. This obviously would help mitigating the issue for a good portion of existing packages that are using node-pre-gyp and prebuild, but for packages that are doing their own thing such as uws, this solution wouldn't work properly.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: nodejs 8.10.0~dfsg-2
ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18
Uname: Linux 4.15.0-24-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Jul 3 05:34:28 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-03-08 (482 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: nodejs
UpgradeStatus: Upgraded to bionic on 2018-05-10 (54 days ago) |
[impact]
Pre-built addons for nodejs built against the 8.10 version, which is what is included in Bionic, will fail to load on Bionic because the version of nodejs there is built using a newer ABI-incompatible openssl version.
[test case]
see comment 4 (and discussion in following comments)
[regression potential]
any nodejs addons built for the current version of nodejs in Bionic will need to be re-built to pick up the different openssl ABI. This appears to be a rather significant list of packages. Any external nodejs addons that were built specifically for the current Bionic nodejs will also start failing, until rebuilt against the upstream nodejs 8.10 version, or the new Bionic nodejs package.
Changing this to use openssl1.0 assumes that the security team will maintain security patches for openssl1.0.
[other info]
alternately, this could be fixed by upgrading the nodejs package in Bionic (and Cosmic) to a newer nodejs - Debian has version 10.4.0 in experimental.
original bug description below.
---
Background:
NodeJS has a native extension API: https://nodejs.org/api/addons.html
It's fairly understood by developers that NodeJS's ABI is stable, and that one module built using a version of nodejs should work on another semantically version compatible of nodejs.
NodeJS exposes various third party libraries to the native module developers. Quote from the addons developers page: "Node.js includes a number of other statically linked libraries including OpenSSL. These other libraries are located in the deps/ directory in the Node.js source tree. Only the libuv,i OpenSSL, V8 and zlib symbols are purposefully re-exported by Node.js and may be used to various extents by Addons."
It's fairly understood by developers that native modules have the same ABI guarantee than the rest of the node API.
The NodeJS ecosystem uses native modules extensively, and it's fairly common for developers to publish precompiled versions of their extensions so that the typical end-user can simply npm install their dependencies without worrying about having a compiler installed. Some packages will do their own thing (see for instance https://www.npmjs.com/package/uws), while others will rely on third party extensions to facilitate their work. See for instance prebuild (https://www.npmjs.com/package/prebuild) that has a handful of dependents, or node-pre-gyp (https://www.npmjs.com/package/node-pre-gyp) that has north of 350 dependents. So the nodejs ecosystem has roughly 400 native packages that are publishing prebuilt versions of their extensions.
Problem with the Ubuntu nodejs package:
Put simply, it breaks prebuilt packages that depend on OpenSSL. NodeJS 8.10.0 officially comes with OpenSSL 1.0.2n, while the NodeJS 8.10.0 that comes with the Ubuntu package exposes OpenSSL 1.1.0g.
Since there are ABI breakages between OpenSSL 1.0.2 and 1.1.0, these ABI breakages are bubbling up to any prebuilt native addon.
Here is an example:
https://github.com/nicolasnoble/openssl-nodejs-ubuntu-demo
If you build this package under the mainline nodejs, it will try to import the following symbols from OpenSSL 1.0.2:
. SSL_library_init
. SSLeay_version
Whereas if you build it under Ubuntu's nodejs, it will try to import the following symbols instead from OpenSSL 1.1.0:
. OPENSSL_init_ssl
. OpenSSL_version
Therefore, trying to load one prebuilt module from one version of the runtime to another will result in a symbol loading error:
node: symbol lookup error: /home/pixel/node-openssl-addon-example/build/Release/openssl_example.node: undefined symbol: SSL_library_init
Incidentally, nodejs 10.5.0 uses OpenSSL 1.1.0h, and compiling the same demo module with this version of node will try to import the proper symbols. Obviously, since the module will be built for the wrong version of the nodejs runtime, it won't load, but the SSL symbols are now proper.
This creates weird bug reports for nodejs extension developers, such as https://github.com/grpc/grpc-node/issues/341
Another example is uws. Trying to use uws in ubuntu's nodejs will result in the same sort of failures. Which means there are at least two packages available out there that are affected by this issue.
I don't think this is easily solvable, and all of my suggestions for fixing it have severe cons. Ubuntu won't want to downgrade their system's OpenSSL for this. Maybe there's a way to get another openssl package for 1.0.2, and have the nodejs runtime for Ubuntu depend on it. Another possible solution would be to radically upgrade nodejs to 10, so that the ABI of OpenSSL will then match properly. But this may be viewed as a too radical upgrade.
One sort of mitigation option would be to get node-pre-gyp and prebuild to recognize that it's running with this version of the nodejs runtime, so that it can recognize and take actions, such as downloading an ubuntu-specific version of the prebuilt extension, or recompiling from sources. This obviously would help mitigating the issue for a good portion of existing packages that are using node-pre-gyp and prebuild, but for packages that are doing their own thing such as uws, this solution wouldn't work properly.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: nodejs 8.10.0~dfsg-2
ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18
Uname: Linux 4.15.0-24-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Jul 3 05:34:28 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-03-08 (482 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: nodejs
UpgradeStatus: Upgraded to bionic on 2018-05-10 (54 days ago) |
|
| 2018-07-25 13:11:43 |
Dan Streetman |
description |
[impact]
Pre-built addons for nodejs built against the 8.10 version, which is what is included in Bionic, will fail to load on Bionic because the version of nodejs there is built using a newer ABI-incompatible openssl version.
[test case]
see comment 4 (and discussion in following comments)
[regression potential]
any nodejs addons built for the current version of nodejs in Bionic will need to be re-built to pick up the different openssl ABI. This appears to be a rather significant list of packages. Any external nodejs addons that were built specifically for the current Bionic nodejs will also start failing, until rebuilt against the upstream nodejs 8.10 version, or the new Bionic nodejs package.
Changing this to use openssl1.0 assumes that the security team will maintain security patches for openssl1.0.
[other info]
alternately, this could be fixed by upgrading the nodejs package in Bionic (and Cosmic) to a newer nodejs - Debian has version 10.4.0 in experimental.
original bug description below.
---
Background:
NodeJS has a native extension API: https://nodejs.org/api/addons.html
It's fairly understood by developers that NodeJS's ABI is stable, and that one module built using a version of nodejs should work on another semantically version compatible of nodejs.
NodeJS exposes various third party libraries to the native module developers. Quote from the addons developers page: "Node.js includes a number of other statically linked libraries including OpenSSL. These other libraries are located in the deps/ directory in the Node.js source tree. Only the libuv,i OpenSSL, V8 and zlib symbols are purposefully re-exported by Node.js and may be used to various extents by Addons."
It's fairly understood by developers that native modules have the same ABI guarantee than the rest of the node API.
The NodeJS ecosystem uses native modules extensively, and it's fairly common for developers to publish precompiled versions of their extensions so that the typical end-user can simply npm install their dependencies without worrying about having a compiler installed. Some packages will do their own thing (see for instance https://www.npmjs.com/package/uws), while others will rely on third party extensions to facilitate their work. See for instance prebuild (https://www.npmjs.com/package/prebuild) that has a handful of dependents, or node-pre-gyp (https://www.npmjs.com/package/node-pre-gyp) that has north of 350 dependents. So the nodejs ecosystem has roughly 400 native packages that are publishing prebuilt versions of their extensions.
Problem with the Ubuntu nodejs package:
Put simply, it breaks prebuilt packages that depend on OpenSSL. NodeJS 8.10.0 officially comes with OpenSSL 1.0.2n, while the NodeJS 8.10.0 that comes with the Ubuntu package exposes OpenSSL 1.1.0g.
Since there are ABI breakages between OpenSSL 1.0.2 and 1.1.0, these ABI breakages are bubbling up to any prebuilt native addon.
Here is an example:
https://github.com/nicolasnoble/openssl-nodejs-ubuntu-demo
If you build this package under the mainline nodejs, it will try to import the following symbols from OpenSSL 1.0.2:
. SSL_library_init
. SSLeay_version
Whereas if you build it under Ubuntu's nodejs, it will try to import the following symbols instead from OpenSSL 1.1.0:
. OPENSSL_init_ssl
. OpenSSL_version
Therefore, trying to load one prebuilt module from one version of the runtime to another will result in a symbol loading error:
node: symbol lookup error: /home/pixel/node-openssl-addon-example/build/Release/openssl_example.node: undefined symbol: SSL_library_init
Incidentally, nodejs 10.5.0 uses OpenSSL 1.1.0h, and compiling the same demo module with this version of node will try to import the proper symbols. Obviously, since the module will be built for the wrong version of the nodejs runtime, it won't load, but the SSL symbols are now proper.
This creates weird bug reports for nodejs extension developers, such as https://github.com/grpc/grpc-node/issues/341
Another example is uws. Trying to use uws in ubuntu's nodejs will result in the same sort of failures. Which means there are at least two packages available out there that are affected by this issue.
I don't think this is easily solvable, and all of my suggestions for fixing it have severe cons. Ubuntu won't want to downgrade their system's OpenSSL for this. Maybe there's a way to get another openssl package for 1.0.2, and have the nodejs runtime for Ubuntu depend on it. Another possible solution would be to radically upgrade nodejs to 10, so that the ABI of OpenSSL will then match properly. But this may be viewed as a too radical upgrade.
One sort of mitigation option would be to get node-pre-gyp and prebuild to recognize that it's running with this version of the nodejs runtime, so that it can recognize and take actions, such as downloading an ubuntu-specific version of the prebuilt extension, or recompiling from sources. This obviously would help mitigating the issue for a good portion of existing packages that are using node-pre-gyp and prebuild, but for packages that are doing their own thing such as uws, this solution wouldn't work properly.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: nodejs 8.10.0~dfsg-2
ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18
Uname: Linux 4.15.0-24-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Jul 3 05:34:28 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-03-08 (482 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: nodejs
UpgradeStatus: Upgraded to bionic on 2018-05-10 (54 days ago) |
[impact]
Pre-built addons for nodejs built against the 8.10 version, which is what is included in Bionic, will fail to load on Bionic because the version of nodejs there is built using a newer ABI-incompatible openssl version.
[test case]
see comment 4 (and discussion in following comments)
[regression potential]
any nodejs addons built for the current version of nodejs in Bionic will need to be re-built to pick up the different openssl ABI. This appears to be a rather significant list of packages. Any external nodejs addons that were built specifically for the current Bionic nodejs will also start failing, until rebuilt against the upstream nodejs 8.10 version, or the new Bionic nodejs package.
Changing this to use openssl1.0 assumes that the security team will maintain security patches for openssl1.0.
[other info]
alternately, this could be fixed by upgrading the nodejs package in Bionic (and Cosmic) to a newer nodejs - Debian has version 10.4.0 in experimental.
also the debian bug 904274 has quite a bit of discussion.
original bug description below.
---
Background:
NodeJS has a native extension API: https://nodejs.org/api/addons.html
It's fairly understood by developers that NodeJS's ABI is stable, and that one module built using a version of nodejs should work on another semantically version compatible of nodejs.
NodeJS exposes various third party libraries to the native module developers. Quote from the addons developers page: "Node.js includes a number of other statically linked libraries including OpenSSL. These other libraries are located in the deps/ directory in the Node.js source tree. Only the libuv,i OpenSSL, V8 and zlib symbols are purposefully re-exported by Node.js and may be used to various extents by Addons."
It's fairly understood by developers that native modules have the same ABI guarantee than the rest of the node API.
The NodeJS ecosystem uses native modules extensively, and it's fairly common for developers to publish precompiled versions of their extensions so that the typical end-user can simply npm install their dependencies without worrying about having a compiler installed. Some packages will do their own thing (see for instance https://www.npmjs.com/package/uws), while others will rely on third party extensions to facilitate their work. See for instance prebuild (https://www.npmjs.com/package/prebuild) that has a handful of dependents, or node-pre-gyp (https://www.npmjs.com/package/node-pre-gyp) that has north of 350 dependents. So the nodejs ecosystem has roughly 400 native packages that are publishing prebuilt versions of their extensions.
Problem with the Ubuntu nodejs package:
Put simply, it breaks prebuilt packages that depend on OpenSSL. NodeJS 8.10.0 officially comes with OpenSSL 1.0.2n, while the NodeJS 8.10.0 that comes with the Ubuntu package exposes OpenSSL 1.1.0g.
Since there are ABI breakages between OpenSSL 1.0.2 and 1.1.0, these ABI breakages are bubbling up to any prebuilt native addon.
Here is an example:
https://github.com/nicolasnoble/openssl-nodejs-ubuntu-demo
If you build this package under the mainline nodejs, it will try to import the following symbols from OpenSSL 1.0.2:
. SSL_library_init
. SSLeay_version
Whereas if you build it under Ubuntu's nodejs, it will try to import the following symbols instead from OpenSSL 1.1.0:
. OPENSSL_init_ssl
. OpenSSL_version
Therefore, trying to load one prebuilt module from one version of the runtime to another will result in a symbol loading error:
node: symbol lookup error: /home/pixel/node-openssl-addon-example/build/Release/openssl_example.node: undefined symbol: SSL_library_init
Incidentally, nodejs 10.5.0 uses OpenSSL 1.1.0h, and compiling the same demo module with this version of node will try to import the proper symbols. Obviously, since the module will be built for the wrong version of the nodejs runtime, it won't load, but the SSL symbols are now proper.
This creates weird bug reports for nodejs extension developers, such as https://github.com/grpc/grpc-node/issues/341
Another example is uws. Trying to use uws in ubuntu's nodejs will result in the same sort of failures. Which means there are at least two packages available out there that are affected by this issue.
I don't think this is easily solvable, and all of my suggestions for fixing it have severe cons. Ubuntu won't want to downgrade their system's OpenSSL for this. Maybe there's a way to get another openssl package for 1.0.2, and have the nodejs runtime for Ubuntu depend on it. Another possible solution would be to radically upgrade nodejs to 10, so that the ABI of OpenSSL will then match properly. But this may be viewed as a too radical upgrade.
One sort of mitigation option would be to get node-pre-gyp and prebuild to recognize that it's running with this version of the nodejs runtime, so that it can recognize and take actions, such as downloading an ubuntu-specific version of the prebuilt extension, or recompiling from sources. This obviously would help mitigating the issue for a good portion of existing packages that are using node-pre-gyp and prebuild, but for packages that are doing their own thing such as uws, this solution wouldn't work properly.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: nodejs 8.10.0~dfsg-2
ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18
Uname: Linux 4.15.0-24-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Jul 3 05:34:28 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-03-08 (482 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: nodejs
UpgradeStatus: Upgraded to bionic on 2018-05-10 (54 days ago) |
|
| 2018-07-25 13:13:12 |
Dan Streetman |
description |
[impact]
Pre-built addons for nodejs built against the 8.10 version, which is what is included in Bionic, will fail to load on Bionic because the version of nodejs there is built using a newer ABI-incompatible openssl version.
[test case]
see comment 4 (and discussion in following comments)
[regression potential]
any nodejs addons built for the current version of nodejs in Bionic will need to be re-built to pick up the different openssl ABI. This appears to be a rather significant list of packages. Any external nodejs addons that were built specifically for the current Bionic nodejs will also start failing, until rebuilt against the upstream nodejs 8.10 version, or the new Bionic nodejs package.
Changing this to use openssl1.0 assumes that the security team will maintain security patches for openssl1.0.
[other info]
alternately, this could be fixed by upgrading the nodejs package in Bionic (and Cosmic) to a newer nodejs - Debian has version 10.4.0 in experimental.
also the debian bug 904274 has quite a bit of discussion.
original bug description below.
---
Background:
NodeJS has a native extension API: https://nodejs.org/api/addons.html
It's fairly understood by developers that NodeJS's ABI is stable, and that one module built using a version of nodejs should work on another semantically version compatible of nodejs.
NodeJS exposes various third party libraries to the native module developers. Quote from the addons developers page: "Node.js includes a number of other statically linked libraries including OpenSSL. These other libraries are located in the deps/ directory in the Node.js source tree. Only the libuv,i OpenSSL, V8 and zlib symbols are purposefully re-exported by Node.js and may be used to various extents by Addons."
It's fairly understood by developers that native modules have the same ABI guarantee than the rest of the node API.
The NodeJS ecosystem uses native modules extensively, and it's fairly common for developers to publish precompiled versions of their extensions so that the typical end-user can simply npm install their dependencies without worrying about having a compiler installed. Some packages will do their own thing (see for instance https://www.npmjs.com/package/uws), while others will rely on third party extensions to facilitate their work. See for instance prebuild (https://www.npmjs.com/package/prebuild) that has a handful of dependents, or node-pre-gyp (https://www.npmjs.com/package/node-pre-gyp) that has north of 350 dependents. So the nodejs ecosystem has roughly 400 native packages that are publishing prebuilt versions of their extensions.
Problem with the Ubuntu nodejs package:
Put simply, it breaks prebuilt packages that depend on OpenSSL. NodeJS 8.10.0 officially comes with OpenSSL 1.0.2n, while the NodeJS 8.10.0 that comes with the Ubuntu package exposes OpenSSL 1.1.0g.
Since there are ABI breakages between OpenSSL 1.0.2 and 1.1.0, these ABI breakages are bubbling up to any prebuilt native addon.
Here is an example:
https://github.com/nicolasnoble/openssl-nodejs-ubuntu-demo
If you build this package under the mainline nodejs, it will try to import the following symbols from OpenSSL 1.0.2:
. SSL_library_init
. SSLeay_version
Whereas if you build it under Ubuntu's nodejs, it will try to import the following symbols instead from OpenSSL 1.1.0:
. OPENSSL_init_ssl
. OpenSSL_version
Therefore, trying to load one prebuilt module from one version of the runtime to another will result in a symbol loading error:
node: symbol lookup error: /home/pixel/node-openssl-addon-example/build/Release/openssl_example.node: undefined symbol: SSL_library_init
Incidentally, nodejs 10.5.0 uses OpenSSL 1.1.0h, and compiling the same demo module with this version of node will try to import the proper symbols. Obviously, since the module will be built for the wrong version of the nodejs runtime, it won't load, but the SSL symbols are now proper.
This creates weird bug reports for nodejs extension developers, such as https://github.com/grpc/grpc-node/issues/341
Another example is uws. Trying to use uws in ubuntu's nodejs will result in the same sort of failures. Which means there are at least two packages available out there that are affected by this issue.
I don't think this is easily solvable, and all of my suggestions for fixing it have severe cons. Ubuntu won't want to downgrade their system's OpenSSL for this. Maybe there's a way to get another openssl package for 1.0.2, and have the nodejs runtime for Ubuntu depend on it. Another possible solution would be to radically upgrade nodejs to 10, so that the ABI of OpenSSL will then match properly. But this may be viewed as a too radical upgrade.
One sort of mitigation option would be to get node-pre-gyp and prebuild to recognize that it's running with this version of the nodejs runtime, so that it can recognize and take actions, such as downloading an ubuntu-specific version of the prebuilt extension, or recompiling from sources. This obviously would help mitigating the issue for a good portion of existing packages that are using node-pre-gyp and prebuild, but for packages that are doing their own thing such as uws, this solution wouldn't work properly.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: nodejs 8.10.0~dfsg-2
ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18
Uname: Linux 4.15.0-24-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Jul 3 05:34:28 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-03-08 (482 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: nodejs
UpgradeStatus: Upgraded to bionic on 2018-05-10 (54 days ago) |
[impact]
Pre-built addons for nodejs built against the 8.10 version, which is what is included in Bionic, will fail to load on Bionic because the version of nodejs there is built using a newer ABI-incompatible openssl version.
[test case]
see comment 4 (and discussion in following comments)
[regression potential]
any nodejs addons built for the current version of nodejs in Bionic will need to be re-built to pick up the different openssl ABI. This appears to be a rather significant list of packages. Any external nodejs addons that were built specifically for the current Bionic nodejs will also start failing, until rebuilt against the upstream nodejs 8.10 version, or the new Bionic nodejs package.
Changing this to use openssl1.0 assumes that the security team will maintain security patches for openssl1.0.
[other info]
alternately, this could be fixed by upgrading the nodejs package in Bionic (and Cosmic) to a newer nodejs - Debian has version 10.4.0 in experimental.
also debian 904274 has quite a bit of discussion.
original bug description below.
---
Background:
NodeJS has a native extension API: https://nodejs.org/api/addons.html
It's fairly understood by developers that NodeJS's ABI is stable, and that one module built using a version of nodejs should work on another semantically version compatible of nodejs.
NodeJS exposes various third party libraries to the native module developers. Quote from the addons developers page: "Node.js includes a number of other statically linked libraries including OpenSSL. These other libraries are located in the deps/ directory in the Node.js source tree. Only the libuv,i OpenSSL, V8 and zlib symbols are purposefully re-exported by Node.js and may be used to various extents by Addons."
It's fairly understood by developers that native modules have the same ABI guarantee than the rest of the node API.
The NodeJS ecosystem uses native modules extensively, and it's fairly common for developers to publish precompiled versions of their extensions so that the typical end-user can simply npm install their dependencies without worrying about having a compiler installed. Some packages will do their own thing (see for instance https://www.npmjs.com/package/uws), while others will rely on third party extensions to facilitate their work. See for instance prebuild (https://www.npmjs.com/package/prebuild) that has a handful of dependents, or node-pre-gyp (https://www.npmjs.com/package/node-pre-gyp) that has north of 350 dependents. So the nodejs ecosystem has roughly 400 native packages that are publishing prebuilt versions of their extensions.
Problem with the Ubuntu nodejs package:
Put simply, it breaks prebuilt packages that depend on OpenSSL. NodeJS 8.10.0 officially comes with OpenSSL 1.0.2n, while the NodeJS 8.10.0 that comes with the Ubuntu package exposes OpenSSL 1.1.0g.
Since there are ABI breakages between OpenSSL 1.0.2 and 1.1.0, these ABI breakages are bubbling up to any prebuilt native addon.
Here is an example:
https://github.com/nicolasnoble/openssl-nodejs-ubuntu-demo
If you build this package under the mainline nodejs, it will try to import the following symbols from OpenSSL 1.0.2:
. SSL_library_init
. SSLeay_version
Whereas if you build it under Ubuntu's nodejs, it will try to import the following symbols instead from OpenSSL 1.1.0:
. OPENSSL_init_ssl
. OpenSSL_version
Therefore, trying to load one prebuilt module from one version of the runtime to another will result in a symbol loading error:
node: symbol lookup error: /home/pixel/node-openssl-addon-example/build/Release/openssl_example.node: undefined symbol: SSL_library_init
Incidentally, nodejs 10.5.0 uses OpenSSL 1.1.0h, and compiling the same demo module with this version of node will try to import the proper symbols. Obviously, since the module will be built for the wrong version of the nodejs runtime, it won't load, but the SSL symbols are now proper.
This creates weird bug reports for nodejs extension developers, such as https://github.com/grpc/grpc-node/issues/341
Another example is uws. Trying to use uws in ubuntu's nodejs will result in the same sort of failures. Which means there are at least two packages available out there that are affected by this issue.
I don't think this is easily solvable, and all of my suggestions for fixing it have severe cons. Ubuntu won't want to downgrade their system's OpenSSL for this. Maybe there's a way to get another openssl package for 1.0.2, and have the nodejs runtime for Ubuntu depend on it. Another possible solution would be to radically upgrade nodejs to 10, so that the ABI of OpenSSL will then match properly. But this may be viewed as a too radical upgrade.
One sort of mitigation option would be to get node-pre-gyp and prebuild to recognize that it's running with this version of the nodejs runtime, so that it can recognize and take actions, such as downloading an ubuntu-specific version of the prebuilt extension, or recompiling from sources. This obviously would help mitigating the issue for a good portion of existing packages that are using node-pre-gyp and prebuild, but for packages that are doing their own thing such as uws, this solution wouldn't work properly.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: nodejs 8.10.0~dfsg-2
ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18
Uname: Linux 4.15.0-24-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Jul 3 05:34:28 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-03-08 (482 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: nodejs
UpgradeStatus: Upgraded to bionic on 2018-05-10 (54 days ago) |
|
| 2018-07-25 15:51:43 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2018-07-25 16:21:31 |
Ubuntu Foundations Team Bug Bot |
tags |
amd64 apport-bug bionic sts-sponsor-ddstreet |
amd64 apport-bug bionic patch sts-sponsor-ddstreet |
|
| 2018-08-02 18:23:41 |
Steve Langasek |
nodejs (Ubuntu Bionic): status |
In Progress |
Won't Fix |
|
| 2018-08-02 20:05:26 |
Dan Streetman |
nodejs (Ubuntu Bionic): assignee |
Dan Streetman (ddstreet) |
|
|
| 2018-08-02 20:05:29 |
Dan Streetman |
nodejs (Ubuntu Cosmic): assignee |
Dan Streetman (ddstreet) |
|
|
| 2018-08-03 05:12:16 |
Nicolas Noble |
bug watch added |
|
https://github.com/nodejs/node-gyp/issues/1415 |
|
| 2018-08-03 17:50:25 |
Steve Langasek |
bug |
|
|
added subscriber Steve Langasek |
| 2018-08-07 21:07:42 |
Steve Langasek |
description |
[impact]
Pre-built addons for nodejs built against the 8.10 version, which is what is included in Bionic, will fail to load on Bionic because the version of nodejs there is built using a newer ABI-incompatible openssl version.
[test case]
see comment 4 (and discussion in following comments)
[regression potential]
any nodejs addons built for the current version of nodejs in Bionic will need to be re-built to pick up the different openssl ABI. This appears to be a rather significant list of packages. Any external nodejs addons that were built specifically for the current Bionic nodejs will also start failing, until rebuilt against the upstream nodejs 8.10 version, or the new Bionic nodejs package.
Changing this to use openssl1.0 assumes that the security team will maintain security patches for openssl1.0.
[other info]
alternately, this could be fixed by upgrading the nodejs package in Bionic (and Cosmic) to a newer nodejs - Debian has version 10.4.0 in experimental.
also debian 904274 has quite a bit of discussion.
original bug description below.
---
Background:
NodeJS has a native extension API: https://nodejs.org/api/addons.html
It's fairly understood by developers that NodeJS's ABI is stable, and that one module built using a version of nodejs should work on another semantically version compatible of nodejs.
NodeJS exposes various third party libraries to the native module developers. Quote from the addons developers page: "Node.js includes a number of other statically linked libraries including OpenSSL. These other libraries are located in the deps/ directory in the Node.js source tree. Only the libuv,i OpenSSL, V8 and zlib symbols are purposefully re-exported by Node.js and may be used to various extents by Addons."
It's fairly understood by developers that native modules have the same ABI guarantee than the rest of the node API.
The NodeJS ecosystem uses native modules extensively, and it's fairly common for developers to publish precompiled versions of their extensions so that the typical end-user can simply npm install their dependencies without worrying about having a compiler installed. Some packages will do their own thing (see for instance https://www.npmjs.com/package/uws), while others will rely on third party extensions to facilitate their work. See for instance prebuild (https://www.npmjs.com/package/prebuild) that has a handful of dependents, or node-pre-gyp (https://www.npmjs.com/package/node-pre-gyp) that has north of 350 dependents. So the nodejs ecosystem has roughly 400 native packages that are publishing prebuilt versions of their extensions.
Problem with the Ubuntu nodejs package:
Put simply, it breaks prebuilt packages that depend on OpenSSL. NodeJS 8.10.0 officially comes with OpenSSL 1.0.2n, while the NodeJS 8.10.0 that comes with the Ubuntu package exposes OpenSSL 1.1.0g.
Since there are ABI breakages between OpenSSL 1.0.2 and 1.1.0, these ABI breakages are bubbling up to any prebuilt native addon.
Here is an example:
https://github.com/nicolasnoble/openssl-nodejs-ubuntu-demo
If you build this package under the mainline nodejs, it will try to import the following symbols from OpenSSL 1.0.2:
. SSL_library_init
. SSLeay_version
Whereas if you build it under Ubuntu's nodejs, it will try to import the following symbols instead from OpenSSL 1.1.0:
. OPENSSL_init_ssl
. OpenSSL_version
Therefore, trying to load one prebuilt module from one version of the runtime to another will result in a symbol loading error:
node: symbol lookup error: /home/pixel/node-openssl-addon-example/build/Release/openssl_example.node: undefined symbol: SSL_library_init
Incidentally, nodejs 10.5.0 uses OpenSSL 1.1.0h, and compiling the same demo module with this version of node will try to import the proper symbols. Obviously, since the module will be built for the wrong version of the nodejs runtime, it won't load, but the SSL symbols are now proper.
This creates weird bug reports for nodejs extension developers, such as https://github.com/grpc/grpc-node/issues/341
Another example is uws. Trying to use uws in ubuntu's nodejs will result in the same sort of failures. Which means there are at least two packages available out there that are affected by this issue.
I don't think this is easily solvable, and all of my suggestions for fixing it have severe cons. Ubuntu won't want to downgrade their system's OpenSSL for this. Maybe there's a way to get another openssl package for 1.0.2, and have the nodejs runtime for Ubuntu depend on it. Another possible solution would be to radically upgrade nodejs to 10, so that the ABI of OpenSSL will then match properly. But this may be viewed as a too radical upgrade.
One sort of mitigation option would be to get node-pre-gyp and prebuild to recognize that it's running with this version of the nodejs runtime, so that it can recognize and take actions, such as downloading an ubuntu-specific version of the prebuilt extension, or recompiling from sources. This obviously would help mitigating the issue for a good portion of existing packages that are using node-pre-gyp and prebuild, but for packages that are doing their own thing such as uws, this solution wouldn't work properly.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: nodejs 8.10.0~dfsg-2
ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18
Uname: Linux 4.15.0-24-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Jul 3 05:34:28 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-03-08 (482 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: nodejs
UpgradeStatus: Upgraded to bionic on 2018-05-10 (54 days ago) |
[impact]
Pre-built addons for nodejs built against the 8.10 version, which is what is included in Bionic, will fail to load on Bionic because the version of nodejs there is built using a newer ABI-incompatible openssl version.
[test case]
see comment 4 (and discussion in following comments)
[regression potential]
Although this SRU changes the ABI of nodejs that is exposed to binary add-ons, the practical regression potential for this ABI change is minimal. The archive has been scanned to confirm there are no reverse-dependencies in Ubuntu which use this part of the ABI, and it is not feasible to build third-party binaries that are compatible with nodejs as shipped in 18.04 because the gyp build system used by the nodejs ecosystem exposes system headers that don't match the symbols exported by the current Ubuntu nodejs built against OpenSSL 1.1.
Thus, the greatest risk of regression is from someone manually working around this gyp incompatibility in order to build an add-on which uses these symbols. This risk is negligible.
Changing this to use openssl1.0 assumes that the security team will maintain security patches for openssl1.0.
There is no risk of regression in protocol compatibility by switching back from openssl 1.1 to openssl 1.0, because TLS 1.3 support has not yet landed in the openssl package in 18.04.
[other info]
alternately, this could be fixed by upgrading the nodejs package in Bionic (and Cosmic) to a newer nodejs - Debian has version 10.4.0 in experimental.
also debian 904274 has quite a bit of discussion.
original bug description below.
---
Background:
NodeJS has a native extension API: https://nodejs.org/api/addons.html
It's fairly understood by developers that NodeJS's ABI is stable, and that one module built using a version of nodejs should work on another semantically version compatible of nodejs.
NodeJS exposes various third party libraries to the native module developers. Quote from the addons developers page: "Node.js includes a number of other statically linked libraries including OpenSSL. These other libraries are located in the deps/ directory in the Node.js source tree. Only the libuv,i OpenSSL, V8 and zlib symbols are purposefully re-exported by Node.js and may be used to various extents by Addons."
It's fairly understood by developers that native modules have the same ABI guarantee than the rest of the node API.
The NodeJS ecosystem uses native modules extensively, and it's fairly common for developers to publish precompiled versions of their extensions so that the typical end-user can simply npm install their dependencies without worrying about having a compiler installed. Some packages will do their own thing (see for instance https://www.npmjs.com/package/uws), while others will rely on third party extensions to facilitate their work. See for instance prebuild (https://www.npmjs.com/package/prebuild) that has a handful of dependents, or node-pre-gyp (https://www.npmjs.com/package/node-pre-gyp) that has north of 350 dependents. So the nodejs ecosystem has roughly 400 native packages that are publishing prebuilt versions of their extensions.
Problem with the Ubuntu nodejs package:
Put simply, it breaks prebuilt packages that depend on OpenSSL. NodeJS 8.10.0 officially comes with OpenSSL 1.0.2n, while the NodeJS 8.10.0 that comes with the Ubuntu package exposes OpenSSL 1.1.0g.
Since there are ABI breakages between OpenSSL 1.0.2 and 1.1.0, these ABI breakages are bubbling up to any prebuilt native addon.
Here is an example:
https://github.com/nicolasnoble/openssl-nodejs-ubuntu-demo
If you build this package under the mainline nodejs, it will try to import the following symbols from OpenSSL 1.0.2:
. SSL_library_init
. SSLeay_version
Whereas if you build it under Ubuntu's nodejs, it will try to import the following symbols instead from OpenSSL 1.1.0:
. OPENSSL_init_ssl
. OpenSSL_version
Therefore, trying to load one prebuilt module from one version of the runtime to another will result in a symbol loading error:
node: symbol lookup error: /home/pixel/node-openssl-addon-example/build/Release/openssl_example.node: undefined symbol: SSL_library_init
Incidentally, nodejs 10.5.0 uses OpenSSL 1.1.0h, and compiling the same demo module with this version of node will try to import the proper symbols. Obviously, since the module will be built for the wrong version of the nodejs runtime, it won't load, but the SSL symbols are now proper.
This creates weird bug reports for nodejs extension developers, such as https://github.com/grpc/grpc-node/issues/341
Another example is uws. Trying to use uws in ubuntu's nodejs will result in the same sort of failures. Which means there are at least two packages available out there that are affected by this issue.
I don't think this is easily solvable, and all of my suggestions for fixing it have severe cons. Ubuntu won't want to downgrade their system's OpenSSL for this. Maybe there's a way to get another openssl package for 1.0.2, and have the nodejs runtime for Ubuntu depend on it. Another possible solution would be to radically upgrade nodejs to 10, so that the ABI of OpenSSL will then match properly. But this may be viewed as a too radical upgrade.
One sort of mitigation option would be to get node-pre-gyp and prebuild to recognize that it's running with this version of the nodejs runtime, so that it can recognize and take actions, such as downloading an ubuntu-specific version of the prebuilt extension, or recompiling from sources. This obviously would help mitigating the issue for a good portion of existing packages that are using node-pre-gyp and prebuild, but for packages that are doing their own thing such as uws, this solution wouldn't work properly.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: nodejs 8.10.0~dfsg-2
ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18
Uname: Linux 4.15.0-24-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Jul 3 05:34:28 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-03-08 (482 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: nodejs
UpgradeStatus: Upgraded to bionic on 2018-05-10 (54 days ago) |
|
| 2018-08-07 21:18:56 |
Steve Langasek |
nodejs (Ubuntu Bionic): status |
Won't Fix |
Incomplete |
|
| 2018-08-10 21:54:12 |
Steve Langasek |
description |
[impact]
Pre-built addons for nodejs built against the 8.10 version, which is what is included in Bionic, will fail to load on Bionic because the version of nodejs there is built using a newer ABI-incompatible openssl version.
[test case]
see comment 4 (and discussion in following comments)
[regression potential]
Although this SRU changes the ABI of nodejs that is exposed to binary add-ons, the practical regression potential for this ABI change is minimal. The archive has been scanned to confirm there are no reverse-dependencies in Ubuntu which use this part of the ABI, and it is not feasible to build third-party binaries that are compatible with nodejs as shipped in 18.04 because the gyp build system used by the nodejs ecosystem exposes system headers that don't match the symbols exported by the current Ubuntu nodejs built against OpenSSL 1.1.
Thus, the greatest risk of regression is from someone manually working around this gyp incompatibility in order to build an add-on which uses these symbols. This risk is negligible.
Changing this to use openssl1.0 assumes that the security team will maintain security patches for openssl1.0.
There is no risk of regression in protocol compatibility by switching back from openssl 1.1 to openssl 1.0, because TLS 1.3 support has not yet landed in the openssl package in 18.04.
[other info]
alternately, this could be fixed by upgrading the nodejs package in Bionic (and Cosmic) to a newer nodejs - Debian has version 10.4.0 in experimental.
also debian 904274 has quite a bit of discussion.
original bug description below.
---
Background:
NodeJS has a native extension API: https://nodejs.org/api/addons.html
It's fairly understood by developers that NodeJS's ABI is stable, and that one module built using a version of nodejs should work on another semantically version compatible of nodejs.
NodeJS exposes various third party libraries to the native module developers. Quote from the addons developers page: "Node.js includes a number of other statically linked libraries including OpenSSL. These other libraries are located in the deps/ directory in the Node.js source tree. Only the libuv,i OpenSSL, V8 and zlib symbols are purposefully re-exported by Node.js and may be used to various extents by Addons."
It's fairly understood by developers that native modules have the same ABI guarantee than the rest of the node API.
The NodeJS ecosystem uses native modules extensively, and it's fairly common for developers to publish precompiled versions of their extensions so that the typical end-user can simply npm install their dependencies without worrying about having a compiler installed. Some packages will do their own thing (see for instance https://www.npmjs.com/package/uws), while others will rely on third party extensions to facilitate their work. See for instance prebuild (https://www.npmjs.com/package/prebuild) that has a handful of dependents, or node-pre-gyp (https://www.npmjs.com/package/node-pre-gyp) that has north of 350 dependents. So the nodejs ecosystem has roughly 400 native packages that are publishing prebuilt versions of their extensions.
Problem with the Ubuntu nodejs package:
Put simply, it breaks prebuilt packages that depend on OpenSSL. NodeJS 8.10.0 officially comes with OpenSSL 1.0.2n, while the NodeJS 8.10.0 that comes with the Ubuntu package exposes OpenSSL 1.1.0g.
Since there are ABI breakages between OpenSSL 1.0.2 and 1.1.0, these ABI breakages are bubbling up to any prebuilt native addon.
Here is an example:
https://github.com/nicolasnoble/openssl-nodejs-ubuntu-demo
If you build this package under the mainline nodejs, it will try to import the following symbols from OpenSSL 1.0.2:
. SSL_library_init
. SSLeay_version
Whereas if you build it under Ubuntu's nodejs, it will try to import the following symbols instead from OpenSSL 1.1.0:
. OPENSSL_init_ssl
. OpenSSL_version
Therefore, trying to load one prebuilt module from one version of the runtime to another will result in a symbol loading error:
node: symbol lookup error: /home/pixel/node-openssl-addon-example/build/Release/openssl_example.node: undefined symbol: SSL_library_init
Incidentally, nodejs 10.5.0 uses OpenSSL 1.1.0h, and compiling the same demo module with this version of node will try to import the proper symbols. Obviously, since the module will be built for the wrong version of the nodejs runtime, it won't load, but the SSL symbols are now proper.
This creates weird bug reports for nodejs extension developers, such as https://github.com/grpc/grpc-node/issues/341
Another example is uws. Trying to use uws in ubuntu's nodejs will result in the same sort of failures. Which means there are at least two packages available out there that are affected by this issue.
I don't think this is easily solvable, and all of my suggestions for fixing it have severe cons. Ubuntu won't want to downgrade their system's OpenSSL for this. Maybe there's a way to get another openssl package for 1.0.2, and have the nodejs runtime for Ubuntu depend on it. Another possible solution would be to radically upgrade nodejs to 10, so that the ABI of OpenSSL will then match properly. But this may be viewed as a too radical upgrade.
One sort of mitigation option would be to get node-pre-gyp and prebuild to recognize that it's running with this version of the nodejs runtime, so that it can recognize and take actions, such as downloading an ubuntu-specific version of the prebuilt extension, or recompiling from sources. This obviously would help mitigating the issue for a good portion of existing packages that are using node-pre-gyp and prebuild, but for packages that are doing their own thing such as uws, this solution wouldn't work properly.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: nodejs 8.10.0~dfsg-2
ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18
Uname: Linux 4.15.0-24-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Jul 3 05:34:28 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-03-08 (482 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: nodejs
UpgradeStatus: Upgraded to bionic on 2018-05-10 (54 days ago) |
[impact]
Pre-built addons for nodejs built against the 8.10 version, which is what is included in Bionic, will fail to load on Bionic because the version of nodejs there is built using a newer ABI-incompatible openssl version.
[test case]
1. Run 'sudo apt install nodejs npm'
2. Run 'mkdir /tmp/lp.1779863'
3. Run 'cd /tmp/lp.1779863'
4. Run 'npm install grpc'
5. Note that it mentions installing a prebuilt binary from remote.
6. Run 'node' and enter the following code:
> const grpc = require('grpc')
> const creds = grpc.ServerCredentials.createSsl(null, [])
> const server = new grpc.Server()
> server.bind('0.0.0.0:8080', creds)
7. Observe that this results in a crash, with an error like:
node: symbol lookup error:
/tmp/lp.1779863/node_modules/grpc/src/node/extension_binary/node-v57-linux-x64-glibc/grpc_node.node:
undefined symbol: SSL_library_init
8. Run 'npm install node-webcrypto-ossl'.
9. Observe that compilation fails due to a header expectation mismatch.
10. Install nodejs from -proposed.
11. Repeat steps 6-9 and observe that the commands succeed without errors.
[regression potential]
Although this SRU changes the ABI of nodejs that is exposed to binary add-ons, the practical regression potential for this ABI change is minimal. The archive has been scanned to confirm there are no reverse-dependencies in Ubuntu which use this part of the ABI, and it is not feasible to build third-party binaries that are compatible with nodejs as shipped in 18.04 because the gyp build system used by the nodejs ecosystem exposes system headers that don't match the symbols exported by the current Ubuntu nodejs built against OpenSSL 1.1.
Thus, the greatest risk of regression is from someone manually working around this gyp incompatibility in order to build an add-on which uses these symbols. This risk is negligible.
Changing this to use openssl1.0 assumes that the security team will maintain security patches for openssl1.0.
There is no risk of regression in protocol compatibility by switching back from openssl 1.1 to openssl 1.0, because TLS 1.3 support has not yet landed in the openssl package in 18.04.
[other info]
alternately, this could be fixed by upgrading the nodejs package in Bionic (and Cosmic) to a newer nodejs - Debian has version 10.4.0 in experimental.
also debian 904274 has quite a bit of discussion.
original bug description below.
---
Background:
NodeJS has a native extension API: https://nodejs.org/api/addons.html
It's fairly understood by developers that NodeJS's ABI is stable, and that one module built using a version of nodejs should work on another semantically version compatible of nodejs.
NodeJS exposes various third party libraries to the native module developers. Quote from the addons developers page: "Node.js includes a number of other statically linked libraries including OpenSSL. These other libraries are located in the deps/ directory in the Node.js source tree. Only the libuv,i OpenSSL, V8 and zlib symbols are purposefully re-exported by Node.js and may be used to various extents by Addons."
It's fairly understood by developers that native modules have the same ABI guarantee than the rest of the node API.
The NodeJS ecosystem uses native modules extensively, and it's fairly common for developers to publish precompiled versions of their extensions so that the typical end-user can simply npm install their dependencies without worrying about having a compiler installed. Some packages will do their own thing (see for instance https://www.npmjs.com/package/uws), while others will rely on third party extensions to facilitate their work. See for instance prebuild (https://www.npmjs.com/package/prebuild) that has a handful of dependents, or node-pre-gyp (https://www.npmjs.com/package/node-pre-gyp) that has north of 350 dependents. So the nodejs ecosystem has roughly 400 native packages that are publishing prebuilt versions of their extensions.
Problem with the Ubuntu nodejs package:
Put simply, it breaks prebuilt packages that depend on OpenSSL. NodeJS 8.10.0 officially comes with OpenSSL 1.0.2n, while the NodeJS 8.10.0 that comes with the Ubuntu package exposes OpenSSL 1.1.0g.
Since there are ABI breakages between OpenSSL 1.0.2 and 1.1.0, these ABI breakages are bubbling up to any prebuilt native addon.
Here is an example:
https://github.com/nicolasnoble/openssl-nodejs-ubuntu-demo
If you build this package under the mainline nodejs, it will try to import the following symbols from OpenSSL 1.0.2:
. SSL_library_init
. SSLeay_version
Whereas if you build it under Ubuntu's nodejs, it will try to import the following symbols instead from OpenSSL 1.1.0:
. OPENSSL_init_ssl
. OpenSSL_version
Therefore, trying to load one prebuilt module from one version of the runtime to another will result in a symbol loading error:
node: symbol lookup error: /home/pixel/node-openssl-addon-example/build/Release/openssl_example.node: undefined symbol: SSL_library_init
Incidentally, nodejs 10.5.0 uses OpenSSL 1.1.0h, and compiling the same demo module with this version of node will try to import the proper symbols. Obviously, since the module will be built for the wrong version of the nodejs runtime, it won't load, but the SSL symbols are now proper.
This creates weird bug reports for nodejs extension developers, such as https://github.com/grpc/grpc-node/issues/341
Another example is uws. Trying to use uws in ubuntu's nodejs will result in the same sort of failures. Which means there are at least two packages available out there that are affected by this issue.
I don't think this is easily solvable, and all of my suggestions for fixing it have severe cons. Ubuntu won't want to downgrade their system's OpenSSL for this. Maybe there's a way to get another openssl package for 1.0.2, and have the nodejs runtime for Ubuntu depend on it. Another possible solution would be to radically upgrade nodejs to 10, so that the ABI of OpenSSL will then match properly. But this may be viewed as a too radical upgrade.
One sort of mitigation option would be to get node-pre-gyp and prebuild to recognize that it's running with this version of the nodejs runtime, so that it can recognize and take actions, such as downloading an ubuntu-specific version of the prebuilt extension, or recompiling from sources. This obviously would help mitigating the issue for a good portion of existing packages that are using node-pre-gyp and prebuild, but for packages that are doing their own thing such as uws, this solution wouldn't work properly.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: nodejs 8.10.0~dfsg-2
ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18
Uname: Linux 4.15.0-24-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Jul 3 05:34:28 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-03-08 (482 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: nodejs
UpgradeStatus: Upgraded to bionic on 2018-05-10 (54 days ago) |
|
| 2018-08-10 21:57:16 |
Steve Langasek |
nodejs (Ubuntu Bionic): status |
Incomplete |
Fix Committed |
|
| 2018-08-10 21:57:33 |
Steve Langasek |
tags |
amd64 apport-bug bionic patch sts-sponsor-ddstreet |
amd64 apport-bug bionic patch sts-sponsor-ddstreet verification-needed verification-needed-bionic |
|
| 2018-08-11 16:12:56 |
Elana Hashman |
attachment added |
|
Steps 1-9 of test case https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863/+attachment/5174164/+files/nodejs-test.log |
|
| 2018-08-14 12:05:45 |
Dan Streetman |
nodejs (Ubuntu Bionic): assignee |
|
Dan Streetman (ddstreet) |
|
| 2018-08-14 12:05:50 |
Dan Streetman |
nodejs (Ubuntu Cosmic): assignee |
|
Dan Streetman (ddstreet) |
|
| 2018-08-31 18:26:35 |
Dan Streetman |
attachment added |
|
lp1779863-cosmic.debdiff https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863/+attachment/5183085/+files/lp1779863-cosmic.debdiff |
|
| 2018-08-31 18:29:27 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-08-31 18:29:31 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2018-08-31 19:04:23 |
Eric Desrochers |
bug |
|
|
added subscriber Eric Desrochers |
| 2018-09-13 19:34:34 |
Mauricio Faria de Oliveira |
attachment added |
|
nodejs_cosmic_openssl102_libuv121.debdiff https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863/+attachment/5188580/+files/nodejs_cosmic_openssl102_libuv121.debdiff |
|
| 2018-09-13 20:20:57 |
Steve Langasek |
nodejs (Ubuntu Cosmic): status |
In Progress |
Fix Committed |
|
| 2018-09-20 03:55:01 |
Launchpad Janitor |
nodejs (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2018-09-21 13:19:03 |
Mauricio Faria de Oliveira |
tags |
amd64 apport-bug bionic patch sts-sponsor-ddstreet verification-needed verification-needed-bionic |
amd64 apport-bug bionic patch sts-sponsor-ddstreet verification-done verification-done-bionic |
|
| 2018-09-26 06:05:32 |
Launchpad Janitor |
nodejs (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-09-26 06:05:38 |
Chris Halse Rogers |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-12-26 01:59:39 |
Bug Watch Updater |
nodejs (Debian): status |
New |
Fix Released |
|
| 2020-03-05 14:03:07 |
Robie Basak |
tags |
amd64 apport-bug bionic patch sts-sponsor-ddstreet verification-done verification-done-bionic |
amd64 apport-bug bionic bionic-openssl-1.1 patch sts-sponsor-ddstreet verification-done verification-done-bionic |
|
