node-red-node-sqlite dependency `sqlite3` is DEPRECATED and has upstream high severity vuln

[Steve-Mcl]

The sqlite3 package (npm, github) is marked on GH as DEPRECATED and has not been updated for over 2 years

NPM reports an issue with a child dependency tar:

tar  <=7.5.3
Severity: high
node-tar is Vulnerable to Arbitrary File Overwrite and Symlink Poisoning via Insufficient Path Sanitization - https://github.com/advisories/GHSA-8qq5-rm4j-mr97
Race Condition in node-tar Path Reservations via Unicode Ligature Collisions on macOS APFS - https://github.com/advisories/GHSA-r6q2-hw4h-h46w

npm audit:

└─┬ node-red-node-sqlite@1.1.1
  └─┬ sqlite3@5.1.7
    ├─┬ node-gyp@8.4.1
    │ ├─┬ make-fetch-happen@9.1.0
    │ │ └─┬ cacache@15.3.0
    │ │   └── tar@6.2.1 deduped
    │ └── tar@6.2.1 deduped
    └── tar@6.2.1

It seems many packages are moving to better-sqlite3 (it has twice as many downloads as sqlite3 ands is updated frequently) - perhaps it is time to consider a move?

[Steve-Mcl]

FYI this has been touched on before in the forum: https://discourse.nodered.org/t/how-to-increase-connection-pool-in-node-red-node-sqlite-node/75112/5?u=steve-mcl

[dceejay]

yup - makes sense - still waiting for that pull request :-)
(I can probably give it a whirl over next few weeks - but as I said - I'm not really a power user of sqlite so I will only be following the simple read/write path.)

[dceejay]

quick look and yes the API is totally different as the "old" sqlite3 lib async and the better-sqlite3 one is sync - so would need a re-write - of course there are already a couple of contributors nodes - https://flows.nodered.org/search?term=better-sqlite - so 🤷 should we just deprecate - merge - adopt - etc ?

[Steve-Mcl]

Hmmmm.

I wonder if either of those were a fork of node-red-node-sqlite - perhaps we could lift the majority of code required and release a major bump version?

🤔

[dceejay]

Well the icon/colour etc are ver similar so I expect so - and one if a fix/tweak on the other - but they are somewhat different code wise - indeed due to being sync rather than async, and also implementing pooling.