Hi Philip, On Sat, Jan 26, 2019 at 04:26:45PM +0000, [email protected] wrote: > On Sat, 26 Jan 2019, Ervin Hegedüs via Pcre-dev wrote: > > > I don't know inside of PCRE, and the used API (I just fond a > > "bug" on of my project), so I think I have to see, what does it > > mean the ovector. The application can use longest pattern, than > > this... so I guess the 40 isn't the solution for "all cases". > > > > Is there any best practice to calculate the size? What other > > consequence is there, when I increase that size? Eg. more memory > > using, slower runtime...? > > In PCRE2 there *is* a way of dealing with this. Instead of providing a > separate ovector, the application calls a function to create a "match > block" that contains the ovector, and one way of specifying how big the > ovector should be is "as big as necessary for this pattern".
well, may be that'll be problem - now I realised that you wrote that the API is changed, but the library we used (I guess) the old: https://github.com/SpiderLabs/ModSecurity/blob/dc78c0e180d09aa1b2f0ffad1a8d6967e69f984f/src/utils/regex.cc#L46 (also see the line 31., where the macro exists). > More memory, yes, but probably insignificant effect on runtime. that's no problem - the library's size is over 60MB now... :) (The project is the ModSecurity3) > > The "for some reason" is a little bit disquieting :), you mean > > that this result is not deterministic? > > I suspect it's a bug/oversight in the old PCRE1 code, but as I said in > my previous message, I'm not inclined to investigate further. ok, so what do you think? Should we align the library to new API? https://www.pcre.org/current/doc/html/ from this: https://www.pcre.org/original/doc/html/ and our problem solved? Is there any other way that we keep the current one? Eg. as Zoli said icrease the size of OVECTOR? If it is a solution, how should we increase the size? (Note: I've ran into this problem when I started to check the OWASP CRS (Core Rule Set) with new ModSec with several HTTPD's. There is a good testing framework, and one of those checks the SQL injection: https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.2/dev/util/regression-tests/tests/REQUEST-942-APPLICATION-ATTACK-SQLI/942130.yaml with this rule: https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/4ad894096c4100a8a3813b24cd47d51ac8d50cbd/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf#L570 The final pattern "builded" from the more "simple": https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.2/dev/util/regexp-assemble/regexp-942130.data I just wrote these informations, that we don't know, how long can be an expression - most of them are changing and grow fat...) Thanks again, a. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
