Fixed possible regular expression catastrophic backtracking

[marekdedic]

Fixes #95

[marekdedic]

I don't think the failing CI has anything to do with the PR - let me know if it does.

[marekdedic]

Hey, any progress on this? This is a blocking issue for me...

Thanks a lot,
Marek

[pkuczynski]

@marekdedic, apologies for the late reply. Could you provide some tests and changelog entry for this?

[marekdedic]

Hi, thanks for the reply anyway 🙂

I've added a changelog entry, however, I'm a bit stuck with the tests, see #126.

[pkuczynski]

@marekdedic I had a look at the example you provided and after adding ? as you suggest, I am only getting a match on .:

https://regex101.com/r/MlbAhW/1 vs https://regex101.com/r/MlbAhW/2

I don't think this is correct?

[marekdedic]

Hmm, it's not correct. I don't really know how to fix it though, as I am not really sure what the mathOutsideOfBrackets function does...

[pkuczynski]

To be honest, I don't know either. I have not written this package and I am only maintaining it. Approving PR and releasing the new versions. The only person who knows is @anandthakker, but he is not responsive :(

[pkuczynski]

Does not seem to work...

[marekdedic]

Hi,
I looked over it once more and it seems to me that the function matchOutsideOfBrackets(X) checks whether there is the characterX somewhere not inside [] or (). So the match on . would actually be correct. And expanding the regex constructed by mathcOutsideOfBrackets, the non-greedy approach doesn't change the meaning.

So I do actually think this PR is correct, however there is one more thing... We can actually undo #88 with this change and simplify it!

[marekdedic]

(and undoing #88 would allow for testing for catastrophic regexes...)

[marekdedic]

Hi, the PR is now working and with tests for unsafe regexes (not limited to the one in #95)

[marekdedic]

Hmm, so the tests wouldn't catch #95. I've tried switching safe-regex for vuln-regex-detector but that seems to be abandoned... So at least an imperfect test...

[pkuczynski]

As I said before, I am not able to fairly judge the changes. If you confident this is correct, I am fine with merging it and releasing as next version.

[pkuczynski]

And thank you for putting effort into this! :)

[marekdedic]

Hold your horses. I think I've found some more performance issues with this function. Going to go for a different solution to solve it once and for all.

[marekdedic]

Hi, I've reworked it to not use such a horrendous regex but a simpler function instead. Unit tests pass, tried it on 2 of my projects, same output, no performance issues. I think you can merge this now.

[pkuczynski]

Let's give it a try and release it as next major version :)