search

nimbella / aio-cli-plugin-runtime

Nimbella Fork of the Adobe I/O Runtime plugin for Apache OpenWhisk.
https://nimbella.com
Apache License 2.0
2 stars 1 forks source link

Plan for eliminating vulnerabilities which leak into nim #37

Closed joshuaauerbachwatson closed 2 years ago

joshuaauerbachwatson commented 2 years ago

I'm having trouble eliminating some moderate severity vulnerabilities from nim. Actually, it's really just one vulnerability: https://github.com/advisories/GHSA-93q8-gq69-wqmw but we are hit with it by many different dependency paths.

I checked whether we could solve this by rebasing on the latest code from Adobe but that code has the vulnerability also (it also has many other vulnerabilities but they are in its dev dependencies only and I'm ignoring them).

Opening this issue for brief discussion of whether

  1. We should be worrying about moderate severity vulnerabilities at all (as opposed to high). I don't regard this one as very threatening based on reading the description but I'm not a security expert and the easiest policy to follow is one that says all vulnerabilities are bad.
  2. (If we should worry) whether we should be aggressively changing dependencies on our fork versus pressing Adobe to fix this.
  3. (if we are going to try to fix this ourselves) what to do about possible test breakages. Like vulnerabilities, not all test breakages are bad, but it's easiest to just say there should be none. If the breaking test doesn't affect how we use the code in the fork, perhaps we can tolerate, but this will inhibit sending anything upstream.

Looking for some guidance from @rabbah .

rabbah commented 2 years ago

Looking at the brief details in the provided link, the description is "ansi-regex is vulnerable to Inefficient Regular Expression Complexity" and advisory is still processing. The linked fix https://github.com/chalk/ansi-regex/commit/8d1d7cdb586269882c4bdc1b7325d0c58c8f76f9 and https://huntr.dev/bounties/5b3cf33b-ede0-4398-9974-800876dfd994/ suggest we are not likely to be impacted by this given the way this library is used.

joshuaauerbachwatson commented 2 years ago

Ok. Sounds like we tolerate and ignore for the present. We can either close this issue or leave it open as a reminder, up to you.

joshuaauerbachwatson commented 2 years ago

I'm closing this because I've meanwhile discovered that I can eliminate vulnerabilities in the upstream consumer (nimbella-cli in this case) by using the "overrides": object in package.json. This requires npm 8.3 or later, which comes with node 16.x. But, we are now standardizing on that, so we can use this technique.