I think part of the problem is that people aren't distinguishing trusted inputs from untrusted inputs. ReDoS is only a possible problem if untrusted inputs can cause it. Some inputs are trusted, and while it's not crazy to check them (people make mistakes), that's a different kind of concern. ReDoS is a potential security vulnerability, but only in certain special cases.
If arbitrary people can insert arbitrary code into what your service sends, and other people will then run it, then ReDoS isn't even the beginning of your security problems.
Well written, honestly I find this hard, e.g. not using eslint that often, I have made no clear decision yet in which kind code input from npm for example falls.
eslint doesn't scan your mode modules. If it did, it would be untrusted, as they could include as .eslintrc.js file and run arbitrary code. However, they could also include a npm post install script and run arbitrary code, or run arbitrary code when your code imports them, so it's not like eslint changes your risk profile in regards to npm dependencies.
Thanks for taking the time to comment extensively.
so it's not like eslint changes your risk profile in regards to npm dependencies.
Depends. If it is the only dependency from npm, it changes all to that regard. This is perhaps the hard case for me.
they could also include a npm post install script and run arbitrary code
Is there a cheap flag or global parameter to disable that so that the build does not run wild?
In composer there is --no-scripts --no-plugins which effectively can prevent things (and scripts / plugins are bound to root projects so they aren't that far-reaching as in npm by default, but the field of problem is technically the same).
At the end of the day I find clamping such features away as necessary as pinning the tool versions for a stable build. Me is just weak with npm.
Comments
I think part of the problem is that people aren't distinguishing trusted inputs from untrusted inputs. ReDoS is only a possible problem if untrusted inputs can cause it. Some inputs are trusted, and while it's not crazy to check them (people make mistakes), that's a different kind of concern. ReDoS is a potential security vulnerability, but only in certain special cases.
If arbitrary people can insert arbitrary code into what your service sends, and other people will then run it, then ReDoS isn't even the beginning of your security problems.
Well written, honestly I find this hard, e.g. not using eslint that often, I have made no clear decision yet in which kind code input from npm for example falls.
eslint doesn't scan your mode modules. If it did, it would be untrusted, as they could include as .eslintrc.js file and run arbitrary code. However, they could also include a npm post install script and run arbitrary code, or run arbitrary code when your code imports them, so it's not like eslint changes your risk profile in regards to npm dependencies.
Thanks for taking the time to comment extensively.
Depends. If it is the only dependency from npm, it changes all to that regard. This is perhaps the hard case for me.
Is there a cheap flag or global parameter to disable that so that the build does not run wild?
In composer there is --no-scripts --no-plugins which effectively can prevent things (and scripts / plugins are bound to root projects so they aren't that far-reaching as in npm by default, but the field of problem is technically the same).
At the end of the day I find clamping such features away as necessary as pinning the tool versions for a stable build. Me is just weak with npm.