to-regex
to-regex copied to clipboard
dep: safe-regex: bump to 2.0.0
Bump safe-regex to v2.0.0 to address false negatives.
Replacement for #2.
@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" fromsafe-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.
Hello, tested successfully with [email protected]