4 ms·

Node.js – v20.8.1

57 points by bricss 3y ago

lightswitch05 3y ago
This is the changelog for 20.8.1, but it’s important to point out that that 4 of the CVEs were also patched in 18.18.2. Shameless promotion time, I have a little utility that can check a node version for CVEs or EOL: npx node-version-audit@latest --fail-security Or with docker: docker run --rm -t lightswitch05/node-version-audit:latest --version=$(node -e "console.log(process.versions.node)") Some highlights of the tool is zero dependencies and CVEs are sourced directly from NPM changelogs instead of waiting on slow CVE release processes. See the website for more details: https://www.github.developerdan.com/node-version-audit/ https://www.github.developerdan.com/node-version-audit/
MuffinFlavored 3y ago
> CVE-2023-44487: nghttp2 Security Release (High) https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-44487 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4448... https://github.com/nodejs/node/pull/50121/files https://github.com/nodejs/node/pull/50121/files > /* Stream reset rate limiter. If receiving excessive amount of stream resets, GOAWAY will be sent. */ Easy to understand how that "Google thwarted 400,000,000 requests per second" CVE that was popular on here a week ago was worked around.
alberth 3y ago
Is NodeJS becoming more performant & efficient - as competition from Bun/JustJS/etc heat up?
- winrid 3y ago
  It was already pretty performant. The issue is as always runtime type checking. For serious stuff you really want that. Also, async everything is not fun. Simple code executed in a thread pool or whatever is so much easier to reason about.
  - chris222 3y ago
    Worker threads have been around for a bit: https://nodejs.org/api/worker_threads.html https://nodejs.org/api/worker_threads.html
    - winrid 3y ago
      yes and slow AF. also nobody is gonna use worker threads without async to handle API requests in NodeJS - why would you use nodejs then?
  - cypress66 3y ago
    > Simple code executed in a thread pool or whatever is so much easier to reason about. reply Hard disagree. It's much easier to reason about async await because you don't need to worry about preemption. You (generally) don't need mutexes or anything like that.
    - winrid 3y ago
      hard disagree. :) When do you have to worry about synchronization? You don't. Pull DB connection from pool, etc, done. Async await has colored functions, promises, and other atrocities. Even if I have some locking primitives somewhere I'll GLADLY take that over the fucking mess of async stack traces and code executed "next tick" with no trace.
  - sgammon 3y ago
    Performant in what sense?
    - winrid 3y ago
      as in easy to handle tens of thousands requests a second with a few DB calls on a smallish server? do you want a PHD thesus on what performant means?
      - sgammon 3y ago

57 points by bricss 3y ago

This is the changelog for 20.8.1, but it’s important to point out that that 4 of the CVEs were also patched in 18.18.2. Shameless promotion time, I have a little utility that can check a node version for CVEs or EOL: npx node-version-audit@latest --fail-security Or with docker: docker run --rm -t lightswitch05/node-version-audit:latest --version=$(node -e "console.log(process.versions.node)") Some highlights of the tool is zero dependencies and CVEs are sourced directly from NPM changelogs instead of waiting on slow CVE release processes. See the website for more details: https://www.github.developerdan.com/node-version-audit/ https://www.github.developerdan.com/node-version-audit/

MuffinFlavored 3y ago

> CVE-2023-44487: nghttp2 Security Release (High) https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-44487 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4448... https://github.com/nodejs/node/pull/50121/files https://github.com/nodejs/node/pull/50121/files > /* Stream reset rate limiter. If receiving excessive amount of stream resets, GOAWAY will be sent. */ Easy to understand how that "Google thwarted 400,000,000 requests per second" CVE that was popular on here a week ago was worked around.

alberth 3y ago

Is NodeJS becoming more performant & efficient - as competition from Bun/JustJS/etc heat up?

winrid 3y ago
It was already pretty performant. The issue is as always runtime type checking. For serious stuff you really want that. Also, async everything is not fun. Simple code executed in a thread pool or whatever is so much easier to reason about.
- chris222 3y ago
  Worker threads have been around for a bit: https://nodejs.org/api/worker_threads.html https://nodejs.org/api/worker_threads.html
  - winrid 3y ago
    yes and slow AF. also nobody is gonna use worker threads without async to handle API requests in NodeJS - why would you use nodejs then?
- cypress66 3y ago
  > Simple code executed in a thread pool or whatever is so much easier to reason about. reply Hard disagree. It's much easier to reason about async await because you don't need to worry about preemption. You (generally) don't need mutexes or anything like that.
  - winrid 3y ago
    hard disagree. :) When do you have to worry about synchronization? You don't. Pull DB connection from pool, etc, done. Async await has colored functions, promises, and other atrocities. Even if I have some locking primitives somewhere I'll GLADLY take that over the fucking mess of async stack traces and code executed "next tick" with no trace.
- sgammon 3y ago
  Performant in what sense?
  - winrid 3y ago
    as in easy to handle tens of thousands requests a second with a few DB calls on a smallish server? do you want a PHD thesus on what performant means?
    - sgammon 3y ago