Starting today, Node 8 is officially unsupported. What does this mean for Node developers? The circuit breakers for Node 8 access don’t immediately turn off — you can still download it and use it in your source code, but be mindful that the Node team will no longer be "maintaining" the runtime. This means that new features and bug fixes will no longer be applied to the version, and this includes security patches. It's easy to assume that the biggest disadvantages of using an outdated language or runtime version are the hit to performance, but the dangerous risks are really in the security patches (or lack thereof).
Lucky for us, the Node team has a quick turnaround of version releases: every 6 months we get a new version, but that means versions are deprecated at the same rate too. The following is the most up-to-date calendar of the release schedule:
With Node 8 reaching end-of-life, the supported versions of Node will be Node 10, 12, and 13 — until April when Node 14 is released and will replace Node 13 as the "current" version.
Generally changes are expected to live in a Current release for at least 2 weeks before being backported.
Node's release plan explains that changes live in the current release (now Node 13) before being added to active releases (currently Node 10 and Node 12). These changes are made in minor and patch releases of their versions that follow semantic versioning release structure.
Once a release moves into Maintenance mode, only critical bugs, critical security fixes, documentation updates, and updates to ensure consistency and usability of the N-API across LTS releases
Up until yesterday, this meant that Node 8 mostly receives only updates for critical bugs and security patches.
How quickly should I update?
Node is built with web servers in mind, and any use of the HTTPS module is highly reliant on OpenSSL's support of TLS (Transport Layer Socket). Even libraries that are meant to secure other libraries have security vulnerabilities and reach their own end-of-life. This post discusses how Node has updated its own release schedule to stay aligned with the changes happening with OpenSSL.
As for Node upgrades, I would recommend pushing this to the top of any backlog or tech debt list if it's not already there. Unfortunately, tech debt is hard to justify because many teams find a hard time providing a quantitative return on investment, and security debt is no different. Therefore, the sooner its brought up, the better.
Because not all libraries handle dependency end-of-life as eloquently as Node, many end-of-life schedules can be found here: https://endoflife.software.
What version of OpenSSL is my application running?
Even though a supported Node version will ensure that the OpenSSL version in use is supported, some people still have questions about the releases. Node has a command line prompt that you can see all the versions being used:
node -p process.versions
Right now, my local device is using Node 13 because I like to live in the edge. If I run this command in any Node environment, I will see output that looks like this:
{
node: '13.5.0',
v8: '7.9.317.25-node.23',
uv: '1.34.0',
zlib: '1.2.11',
brotli: '1.0.7',
ares: '1.15.0',
modules: '79',
nghttp2: '1.40.0',
napi: '5',
llhttp: '2.0.1',
openssl: '1.1.1d',
cldr: '36.0',
icu: '65.1',
tz: '2019c',
unicode: '12.1'
}
I'll get OpenSSL, V8, and some other useful versions I may be curious about. I use nvm to manage my Node versions locally, so I can switch between Node versions in case I need to see what the underlying differences are in dependencies between code bases.
nvm use 8
node -p process.versions
{ http_parser: '2.8.0',
node: '8.17.0',
v8: '6.2.414.78',
uv: '1.23.2',
zlib: '1.2.11',
ares: '1.10.1-DEV',
modules: '57',
nghttp2: '1.39.2',
napi: '4',
openssl: '1.0.2s',
icu: '60.1',
unicode: '10.0',
cldr: '32.0',
tz: '2017c' }
We can see that the OpenSSL version is lower in Node 8, and using the 1.0.2s version. (Older versions of OpenSSL did not use semvar, so letters were used to represent patches with non-breaking changes.) The -p flag is short for --print, and process.versions is a subset of data from process. With node -p process, you’ll get a whole lot more metadata about the current Node binary.
Will this affect my builds on Heroku?
The short answer is "No", but as previously mentioned, it’s better to upgrade as soon as possible. You’ll still be able to use Node 8 for builds (such as with webpack) and runtime environments (like an express server) for applications on Heroku, but there will be no further updates to the version.
With that said, security patches that aren’t related to SSL/TLS are made to Node too. Just a few weeks ago npm (the package manager which gets installed with Node) had 2 CVEs patched that required quick action from both npm and Node releasers to ensure the vulnerable versions were not being installed.
One more thing…
I almost forgot to even mention this — Heroku dynos are hosted within the platform and accessed via the Heroku Router, which handles TLS/SSL on its own (ie. secure requests to https://<my-app>.herokuapp.com). The encrypted requests get sent to the Heroku router, and a Heroku client will complete the request to a user’s dyno (where the application is running) before returning a response that is sent over TLS as it leaves Heroku again.
While TLS certificates can be managed outside of Heroku and simply added to the application, this is why Node applications have to use the HTTP module for their source code. Heroku users may not even realize that this is the case because setting up an Express server does not require explicitly specifying HTTP, and configuration for HTTPS requires importing Node’s HTTPS module.
Next steps
I’d like to say that upgrading versions is as easy as changing the engine value in the package.json, but it’s a little more involving than that. Take a look at the Node CHANGELOG, test critical libraries used for production and testing, and be sure to understand all the breaking changes between versions—all of these will make an upgrade go much smoother.
Good luck out there! 🎉
Top comments (0)