4 ms·

> It’s important to call out that up until v4 ESLint was vulnerable to a Regular Expression Denial of Service attack (ReDoS). If one points out ReDos 'vulnerab

• woodruffw 4y ago
  Well said. The proliferation of ReDoS "vulnerabilities" has been extremely frustrating (as someone working on accurate and high-signal vulnerability reporting tools), and belies completely perverse incentives in the bug bounty/vulnerability reporting space (reporters are incentivized to obtain CVEs to pressure companies into accepting low-quality reports).
• dwheeler 4y ago
  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.
  • hakre 4y ago
    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.
    • Macha 4y ago
      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.
      • hakre 4y ago
        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.
• dpkirchner 4y ago
  I don't understand the comparison between ReDoS vulnerabilities and TypeScript's type system. Could you elaborate?
  • detaro 4y ago
    ReDoS vulnerabilities in tooling - that's the key point. The "risk" is that if you do something weird in your code, then your linter might take a long time or crash (i.e. by running out memory). The same way that doing crazy things with types can make your compiler take a long time or crash (- type system).
    • dpkirchner 4y ago
      I didn't consider TypeScript tooling. I guess that makes sense since it's usually converted to JavaScript instead of being run directly where errors would affect end users.