dep: safe-regex: bump to 2.0.0

[davisjam]

Bump safe-regex to v2.0.0 to address false negatives.

Replacement for #2.

[davisjam]

@jonschlinkert wrote in #2 here:

edit: out of curiosity, what is your overall opinion about how star height is calculated by safe-regex? Last time I reviewed ret, the library used by safe-regex to tokenize regular expressions, it seemed like ret didn't parse properly, and was inadequate for anything but basic "guesstimates". As I recall, safe-regex was frequently returning false-positives and false-negatives, and it seemed like the cause was a combination of how tokenizing was done by ret and the algorithm used by safe-regex. Because of this, I recently started working on a regex parser to try to create a better algorithm for doing star height calculations. However... if safe-regex is "good enough" in your opinion, I won't worry about it too much.

Let's see...

what is your overall opinion about how star height is calculated by safe-regex?

safe-regex v2.0.0 switches from ret to @DmitrySoshnikov's regexp-tree module which has a more expressive API.

Because of this, I recently started working on a regex parser to try to create a better algorithm for doing star height calculations

I recommend you check if regexp-tree will suffice for your purposes.

As I recall, safe-regex was frequently returning false-positives and false-negatives, and it seemed like the cause was a combination of how tokenizing was done by ret and the algorithm used by safe-regex

• safe-regex v2.0.0 should have no false negatives related to star height. However, there are other means of achieving super-linear regex behavior, so a "safe" from safe-regex is by no means a guarantee that you are safe from super-linear (nor even exponential) behavior. See my paper on the topic, most notably the other anti-patterns listed in section 5.1.1. I am planning to add tests for these anti-patterns into a future release of safe-regex.
• However, false positives are entirely possible. This happens when there are "anchors" within the nesting that prevent combinatorial explosion. For example, /(ab+)+/ is not vulnerable but safe-regex will report it as such. More sophisticated analysis is needed, e.g. using the super-linear regex detectors queried through my vuln-regex-detector project.

[guimard]

Hello, tested successfully with [email protected]