Skip to content

Conversation

@swissspidy
Copy link
Member

Fixes #117

@swissspidy swissspidy added this to the 2.4.0 milestone May 2, 2022
@swissspidy swissspidy requested a review from a team as a code owner May 2, 2022 12:03
@schlessera
Copy link
Member

This just gets rid of multibyte support for the regular expressions. Is this the right fix here? I guess it is unlikely to have issues from that due to the fact we're string-matching a full filename or similar against a filepath - but it is not entirely impossible.

Is it technically possible this introduces security issues with malicious filesystem traversal because of bad truncating, for example?

@swissspidy Thoughts?

@swissspidy
Copy link
Member Author

I guess the only other viable solution is to use mb_ereg everywhere and not use PCRE at all, so that usage is consistent and not mixed. But then we should probably make it a required extension.

Not too familiar with either to be able to judge the security implications tbh.

@schlessera
Copy link
Member

Going all-in with mb_ereg() still doesn't solve the issue with preg_quote(), as there is not alternative for mb_* functions.

Merging this for now, but it will probably need to be testing in international setups to see if everything still works as expected.

@swissspidy swissspidy requested a review from schlessera July 4, 2022 16:27
@schlessera schlessera merged commit 483662a into main Jul 4, 2022
@delete-merged-branch delete-merged-branch bot deleted the fix/117-regex branch July 4, 2022 20:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Probable bug: IterableCodeExtractor::calculateMatchScore() - mbstring vs PCRE

3 participants