serialport / node-serialport

Access serial ports with JavaScript. Linux, OSX and Windows. Welcome your robotic JavaScript overlords. Better yet, program them!
https://serialport.io
MIT License
5.84k stars 1.01k forks source link

Update packages to remove vulnerabilities introduced by package hoek and cryptiles #2295

Closed paimon0715 closed 3 years ago

paimon0715 commented 3 years ago

Hi,@reconbot

Issue

2 vulnerabilities (1 high and 1 medium severity) are introduced in serialport: 1.Vulnerability CVE-2018-3728 (medium severity) is detected in package hoek (versions: <4.2.1,>=5.0.0 <5.0.3): https://snyk.io/vuln/npm:hoek:20180212 2.Vulnerability npmjs-advisories-1464 (high severity) is detected in package cryptiles (versions: >=0.0.1 <4.1.2): https://www.npmjs.com/advisories/1464 The above vulnerable packages are transitively referenced by serialport via: 1.serialport@4.0.7 ➔ node-pre-gyp@0.6.39 ➔ hawk@3.1.3 ➔ boom@2.10.1 ➔ hoek@2.16.3 2.serialport@4.0.7 ➔ node-pre-gyp@0.6.39 ➔ hawk@3.1.3 ➔ cryptiles@2.0.5

Solution

Since *_serialport@4.0._ is transitively referenced by 221** downstream projects (e.g., @code-dot-org/johnny-five 0.11.1-cdo.2 (latest version),discobus 1.0.2 (latest version), octalbonescript 1.3.1 (latest version), thing-it-device-microcontroller 0.8.3 (latest version), filament-sty 2.0.18(latest version)),

*_serialport@1.7._ is referenced by 102** downstream projects (e.g., grbljs 0.1.0 (latest version), spark-cli 1.4.2 (latest version), iot-client 2.8.12 (latest version), pimatic-jeelabs 0.8.7 (latest version), pimatic-can 0.1.3 (latest version)),

*_serialport@2.1._ is referenced by 67** downstream projects (e.g., aquila-server 0.2.3 (latest version), node-red-habanero 1.1.20 (latest version), pinoccio 0.1.40 (latest version), coap-shepherd 0.3.1 (latest version), cylon-sphero 0.23.0 (latest version)),

If serialport removes the vulnerable packages from the above versions, then its fixed versions can help downstream users decrease their pain.

Could you help update packages in these versions?

Fixing suggestions

(1)In *_serialport@4.0._**, you can kindly perform the following upgrades (not crossing their major versions): node-pre-gyp ^0.6.32 ➔^0.7.0;

Note: node-pre-gyp@0.7.0,>0.7.0 transitively depends on hoek@4.2.1(a vulnerability CVE-2018-3728 patched version)

(2)In *_serialport@1.7._**, you can kindly perform the following upgrades (not crossing their major versions): node-pre-gyp 0.6.x ➔^0.7.0;

Note: node-pre-gyp@0.7.0,>0.7.0 transitively depends on hoek@4.2.1(a vulnerability CVE-2018-3728 patched version)

(3)In *_serialport@2.1._**, you can kindly perform the following upgrades (not crossing their major versions): node-pre-gyp ^0.6.26 ➔^0.7.0;

Note: node-pre-gyp@0.7.0,>0.7.0 transitively depends on hoek@4.2.1(a vulnerability CVE-2018-3728 patched version)

Thanks for your contributions to the npm ecosystem!

Best regards, Paimon

GazHank commented 3 years ago

Sorry, but I think people will need to be encouraged to upgrade to a more recent version of Serialport as these issues are already addressed there. If someone hasn't updated their package dependencies since 2017 (when version 5 was released) then I suspect there will be a number of security and support issues they will face.

The problem is that version 4 of serial port works with node version 6 and prior which are long out of support. I don't think we could even build them in the GitHub actions environment without issues.

If there are actively used packages where people would like some support to migrate to a newer version of Serialport then I'd be happy to try to help with that migration (I think this would be far safer than for the package to stick with v4)

paimon0715 commented 3 years ago

@GazHank Thanks for your feedback. A lot of downstream users transitively use serialport@1.7. and @2.1. via unmaintained packages (the unmaintained packages cannot upgrade serialport from 1.7. or 2.1. to version 4). This is the root cause.

So if you can kindly release fixed 1.7. and 2.1. versions, the downstream users can avoid introducing vulnerablities.

GazHank commented 3 years ago

If there is no appitite to update the unmaintained packages, but people still want to use them without upgrading then the alternative option might be to use Selective dependency resolutions

I haven't had chance to properly look at the vulnerabilities, but since they relate to the prebuild tooling, rather than the released code, I'm not sure if the vulnerability can actually be triggered.

Since we use Github hosted runners, we are limited to a small set of build environment options, so arent able to build those old versions any more. Additionally if we were to publish an old version without the associated prebuild binaries then it is likely to cause even more issues as the install process for the package will fail when it can't find the tar ball. (and I think most people wont know how to build tthat old code from source)

Of course if you are able to pull any string with the git environments, or help setup some containers or similar to be able to target those old environments then that help would be greatly appreciated :-)

Cheers

Gaz

reconbot commented 3 years ago

I'm happy to depreciate those versions but I'm not updating years old versions of serialport because of vulns in dev deps. They don't even work in Lts versions of nodejs. The download stats (last I checked) were close to zero as well.

reconbot commented 3 years ago

I've depreciated the last versions from each of those major versions and a few others that have had a few downloads in the last few months.

We have a security policy for disclosure if this was something concerning I'd appreciate you not reporting it publicly until we have some time to address it.

GazHank commented 3 years ago

@reconbot sorry for triggering the MSFT bot, I guess it was because I proposed to use dependabot, and ran it against my fork of the repo :-(