Thread: [Mod-security-developers] [Vote] 2.7.5
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
mod-security-developers
|
From: Breno S. <bre...@gm...> - 2013-07-13 01:38:15
|
Hello people, We are planning to release ModSecurity 2.7.5 next week. I would like to ask you guys to help us testing it. To get it please access : https://github.com/SpiderLabs/ModSecurity/tree/remotes/2.7.x I'm planning to start the build process on Wed if we don't have any feedback. Thanks Breno Silva |
|
From: Christian F. <chr...@ti...> - 2013-07-16 08:55:38
|
Hi there, On Fri, Jul 12, 2013 at 10:38:06PM -0300, Breno Silva wrote: > We are planning to release ModSecurity 2.7.5 next week. I would like to ask > you guys to help us testing it. > > To get it please access : > https://github.com/SpiderLabs/ModSecurity/tree/remotes/2.7.x Compiles just fine on Ubuntu 12.04 LTS. Linux Kernel 3.2.0 CPU: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz Apache: 2.2.25 However, make test bails out with the following info: ... libtool: link: gcc -I/opt/apache-2.2.25/include -I/opt/apache-2.2.25/include -I/opt/apache-2.2.25/include -I/usr/include/libxml2 -DWITH_PCRE_STUDY -DMODSEC_PCRE_MATCH_LIMIT=1500 -DMODSEC_PCRE_MATCH_LIMIT_RECURSION=1500 -DREQUEST_EARLY -g -O2 -o msc_test msc_test-msc_test.o msc_test-re.o msc_test-re_operators.o msc_test-re_actions.o msc_test-re_tfns.o msc_test-re_variables.o msc_test-msc_logging.o msc_test-msc_xml.o msc_test-msc_multipart.o msc_test-modsecurity.o msc_test-msc_parsers.o msc_test-msc_util.o msc_test-msc_pcre.o msc_test-msc_unicode.o msc_test-persist_dbm.o msc_test-msc_reqbody.o msc_test-msc_crypt.o msc_test-msc_tree.o msc_test-msc_geo.o msc_test-msc_gsb.o msc_test-acmp.o msc_test-msc_lua.o msc_test-msc_release.o msc_test-libinjection_sqli.o -lrt -lcrypt -lpthread -ldl /usr/lib/x86_64-linux-gnu/libexpat.so /opt/apache-2.2.25/lib/libapr-1.so /opt/apache-2.2.25/lib/libaprutil-1.so -L/usr/lib/x86_64-linux-gnu -lpcre /usr/lib/x86_64-linux-gnu/libxml2.so -pthread -Wl,-rpath -Wl,/opt/apache-2.2.25/lib -Wl,-rpath -Wl,/opt/apache-2.2.25/lib msc_test-re.o: In function `update_rule_target_ex': /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re.c:366: undefined reference to `ap_log_error' /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re.c:436: undefined reference to `ap_log_error' /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re.c:311: undefined reference to `ap_log_error' /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re.c:486: undefined reference to `ap_log_error' /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re.c:377: undefined reference to `ap_log_error' msc_test-re.o:/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re.c:356: more undefined references to `ap_log_error' follow msc_test-re_operators.o: In function `msre_op_rsub_execute': /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re_operators.c:624: undefined reference to `ap_regexec' /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re_operators.c:589: undefined reference to `ap_pregcomp' msc_test-re_operators.o: In function `msre_op_rsub_param_init': /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re_operators.c:516: undefined reference to `ap_pregcomp' collect2: ld returned 1 exit status make[2]: *** [msc_test] Error 1 make[2]: Leaving directory `/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests' make: *** [check-recursive] Error 1 Cheers, Christian -- Wenn ich Naturforschung betreibe, interessieren mich keine Wunder. --- Albertus Magnus, De Generatione et Corruptione, 13. Jh. |
|
From: Christian F. <chr...@ti...> - 2013-07-16 19:05:54
|
Hello Rainer,
On Tue, Jul 16, 2013 at 01:05:08PM +0200, Rainer Jung wrote:
> Hi Christian,
>
> I think when running the unit tests via "make test" you should add
> -DMSC_TEST to CFLAGS. That flag comments all httpd calls and produces
> standalone binaries.
Thanks for the info. True, it's mentioned in the reference guide.
It's just that I used outdated documentation.
Here we have the culprit:
$> make CFLAGS=-DMSC_TEST test
...
Loaded 8 tests from ./op/rx.t
1) op "rx": passed (Pattern match "" at UNIT_TEST.)
2) op "rx": passed
3) op "rx": passed (Pattern match "" at UNIT_TEST.)
4) op "rx": passed (Pattern match "abc" at UNIT_TEST.)
5) op "rx": passed (Pattern match "def" at UNIT_TEST.)
6) op "rx": passed (Pattern match "ghi" at UNIT_TEST.)
7) op "rx": passed
ERROR: Failed to create rule for op "rx": Error creating rule: Error compiling pattern (offset 2): unrecognized character after (? or (?-
Test exited with signal 11.
Executed: ./msc_test "-t" "op" "-n" "rx" "-p" "(?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)" "-D" "0" "-r" "1"
8) op "rx": failed
Passed: 7; Failed: 1
...
576/577 tests passed.
FAIL: run-unit-tests.pl
========================================
1 of 1 test failed
Please report to su...@mo...
========================================
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory `/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests'
make: *** [check-recursive] Error 1
Cheers,
Christian
--
You cannot force ideas. Successful ideas are the result of slow
growth. Ideas do not reach perfection in a day, no matter how much
study is put upon them.
--- Alexander Graham Bell
|
|
From: Rainer J. <rai...@ki...> - 2013-07-16 10:03:05
|
Hi breno, On 13.07.2013 03:38, Breno Silva wrote: > Hello people, > > We are planning to release ModSecurity 2.7.5 next week. I would like to > ask you guys to help us testing it. > > To get it please access : > https://github.com/SpiderLabs/ModSecurity/tree/remotes/2.7.x > > I'm planning to start the build process on Wed if we don't have any > feedback. If you really want to get quality feedback, I think you should provide an RC tarball. Otherwise people will have to run the autogen.sh script using locally installed auto tools and you get to much uncontrolled variation for the test results. Note that autogen.sh produces some warnings here (see below). Test report: - platform Solaris 10 Sparc, 32 bit build - gcc 4.8.1 - httpd 2.4.4 - pcre 8.32 - libxml2 2.9.0 - build succeeds - "make test" with -DMSC_TEST in CFLAGS produces no failure - no functional tests done autogen.sh output: libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build'. libtoolize: copying file `build/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `build'. libtoolize: copying file `build/libtool.m4' libtoolize: copying file `build/ltoptions.m4' libtoolize: copying file `build/ltsugar.m4' libtoolize: copying file `build/ltversion.m4' libtoolize: copying file `build/lt~obsolete.m4' configure.ac:695: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd build/find_lua.m4:7: CHECK_LUA is expanded from... configure.ac:695: the top level configure.ac:695: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd build/find_lua.m4:7: CHECK_LUA is expanded from... configure.ac:695: the top level configure.ac:695: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd build/find_lua.m4:7: CHECK_LUA is expanded from... configure.ac:695: the top level configure.ac:695: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd build/find_lua.m4:7: CHECK_LUA is expanded from... configure.ac:695: the top level configure.ac:695: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd build/find_lua.m4:7: CHECK_LUA is expanded from... configure.ac:695: the top level configure.ac:695: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd build/find_lua.m4:7: CHECK_LUA is expanded from... configure.ac:695: the top level configure.ac:695: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd build/find_lua.m4:7: CHECK_LUA is expanded from... configure.ac:695: the top level configure.ac:695: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd build/find_lua.m4:7: CHECK_LUA is expanded from... configure.ac:695: the top level mlogc/Makefile.am:3: warning: compiling 'mlogc.c' with per-target flags requires 'AM_PROG_CC_C_O' in 'configure.ac' standalone/Makefile.am:75: warning: whitespace following trailing backslash configure.ac:695: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd build/find_lua.m4:7: CHECK_LUA is expanded from... configure.ac:695: the top level configure.ac:695: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd build/find_lua.m4:7: CHECK_LUA is expanded from... configure.ac:695: the top level mlogc/Makefile.am:3: warning: compiling 'mlogc.c' with per-target flags requires 'AM_PROG_CC_C_O' in 'configure.ac' standalone/Makefile.am:75: warning: whitespace following trailing backslash configure.ac:695: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd build/find_lua.m4:7: CHECK_LUA is expanded from... configure.ac:695: the top level Regards, Rainer |
|
From: Rainer J. <rai...@ki...> - 2013-07-16 11:05:21
|
On 16.07.2013 10:55, Christian Folini wrote: > Hi there, > > On Fri, Jul 12, 2013 at 10:38:06PM -0300, Breno Silva wrote: >> We are planning to release ModSecurity 2.7.5 next week. I would like to ask >> you guys to help us testing it. >> >> To get it please access : >> https://github.com/SpiderLabs/ModSecurity/tree/remotes/2.7.x > > Compiles just fine on Ubuntu 12.04 LTS. > Linux Kernel 3.2.0 > CPU: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz > Apache: 2.2.25 > > However, make test bails out with the following info: > > ... > libtool: link: gcc -I/opt/apache-2.2.25/include -I/opt/apache-2.2.25/include -I/opt/apache-2.2.25/include -I/usr/include/libxml2 -DWITH_PCRE_STUDY -DMODSEC_PCRE_MATCH_LIMIT=1500 -DMODSEC_PCRE_MATCH_LIMIT_RECURSION=1500 -DREQUEST_EARLY -g -O2 -o msc_test msc_test-msc_test.o msc_test-re.o msc_test-re_operators.o msc_test-re_actions.o msc_test-re_tfns.o msc_test-re_variables.o msc_test-msc_logging.o msc_test-msc_xml.o msc_test-msc_multipart.o msc_test-modsecurity.o msc_test-msc_parsers.o msc_test-msc_util.o msc_test-msc_pcre.o msc_test-msc_unicode.o msc_test-persist_dbm.o msc_test-msc_reqbody.o msc_test-msc_crypt.o msc_test-msc_tree.o msc_test-msc_geo.o msc_test-msc_gsb.o msc_test-acmp.o msc_test-msc_lua.o msc_test-msc_release.o msc_test-libinjection_sqli.o -lrt -lcrypt -lpthread -ldl /usr/lib/x86_64-linux-gnu/libexpat.so /opt/apache-2.2.25/lib/libapr-1.so /opt/apache-2.2.25/lib/libaprutil-1.so -L/usr/lib/x86_64-linux-gnu -lpcre /usr/lib/x86_64-linux-gnu/libxml2.so -pthread ! -Wl,-rpa th -Wl,/opt/apache-2.2.25/lib -Wl,-rpath -Wl,/opt/apache-2.2.25/lib > msc_test-re.o: In function `update_rule_target_ex': > /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re.c:366: undefined reference to `ap_log_error' > /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re.c:436: undefined reference to `ap_log_error' > /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re.c:311: undefined reference to `ap_log_error' > /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re.c:486: undefined reference to `ap_log_error' > /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re.c:377: undefined reference to `ap_log_error' > msc_test-re.o:/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re.c:356: more undefined references to `ap_log_error' follow > msc_test-re_operators.o: In function `msre_op_rsub_execute': > /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re_operators.c:624: undefined reference to `ap_regexec' > /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re_operators.c:589: undefined reference to `ap_pregcomp' > msc_test-re_operators.o: In function `msre_op_rsub_param_init': > /usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests/../apache2/re_operators.c:516: undefined reference to `ap_pregcomp' > collect2: ld returned 1 exit status > make[2]: *** [msc_test] Error 1 > make[2]: Leaving directory `/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests' > make[1]: *** [check-am] Error 2 > make[1]: Leaving directory `/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests' > make: *** [check-recursive] Error 1 Hi Christian, I think when running the unit tests via "make test" you should add -DMSC_TEST to CFLAGS. That flag comments all httpd calls and produces standalone binaries. Regards, Rainer |
|
From: Rainer J. <rai...@ki...> - 2013-07-16 20:15:42
|
On 16.07.2013 21:05, Christian Folini wrote:
> Hello Rainer,
>
> On Tue, Jul 16, 2013 at 01:05:08PM +0200, Rainer Jung wrote:
>> Hi Christian,
>>
>> I think when running the unit tests via "make test" you should add
>> -DMSC_TEST to CFLAGS. That flag comments all httpd calls and produces
>> standalone binaries.
>
> Thanks for the info. True, it's mentioned in the reference guide.
> It's just that I used outdated documentation.
>
> Here we have the culprit:
> $> make CFLAGS=-DMSC_TEST test
> ...
> Loaded 8 tests from ./op/rx.t
> 1) op "rx": passed (Pattern match "" at UNIT_TEST.)
> 2) op "rx": passed
> 3) op "rx": passed (Pattern match "" at UNIT_TEST.)
> 4) op "rx": passed (Pattern match "abc" at UNIT_TEST.)
> 5) op "rx": passed (Pattern match "def" at UNIT_TEST.)
> 6) op "rx": passed (Pattern match "ghi" at UNIT_TEST.)
> 7) op "rx": passed
> ERROR: Failed to create rule for op "rx": Error creating rule: Error compiling pattern (offset 2): unrecognized character after (? or (?-
> Test exited with signal 11.
> Executed: ./msc_test "-t" "op" "-n" "rx" "-p" "(?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)" "-D" "0" "-r" "1"
> 8) op "rx": failed
> Passed: 7; Failed: 1
> ...
> 576/577 tests passed.
> FAIL: run-unit-tests.pl
> ========================================
> 1 of 1 test failed
> Please report to su...@mo...
> ========================================
> make[2]: *** [check-TESTS] Error 1
> make[2]: Leaving directory `/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests'
> make[1]: *** [check-am] Error 2
> make[1]: Leaving directory `/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests'
> make: *** [check-recursive] Error 1
I was curious why this didn't fail for me. I vaguely remember other
users had reported the same problem before. So here's what I think is
the explanation:
The original pattern in the unit test is in op/rx.t:
qr/^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$/i
The pattern is read by the perl script run-unit-tests.pl. Before Perl
5.14 the qr was converted to:
(?i-xsm:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)
Starting with Perl 5.14 there's a new syntax and the pattern results in
(?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)
(See e.g. http://perldoc.perl.org/perlre.html#Extended-Patterns, there
look for "Starting in Perl 5.14").
Now the unit tests feed the internal representation to the compiled
msc_test binary, which calls the PCRE library to handle the regexp.
Unfortunately the PCRE library only accepts the old way of expressing
this pattern, not the new ?^ syntax.
So if you run the unit tests with a Perl before 5.14 they succeed, with
a newer Perl they fail, because a Perl pre-compiled pattern might no
longer be compatible with PCRE (despite what PCRE means).
I didn't find a bug report for the missing ?^ syntax in the PCRE bug
tracker, but "?^" is not the best token to start a search with.
Regards,
Rainer
|
|
From: Breno S. <bre...@gm...> - 2013-07-16 20:17:59
|
I will update this rx test
Thanks
Breno
On Tue, Jul 16, 2013 at 5:15 PM, Rainer Jung <rai...@ki...>wrote:
> On 16.07.2013 21:05, Christian Folini wrote:
> > Hello Rainer,
> >
> > On Tue, Jul 16, 2013 at 01:05:08PM +0200, Rainer Jung wrote:
> >> Hi Christian,
> >>
> >> I think when running the unit tests via "make test" you should add
> >> -DMSC_TEST to CFLAGS. That flag comments all httpd calls and produces
> >> standalone binaries.
> >
> > Thanks for the info. True, it's mentioned in the reference guide.
> > It's just that I used outdated documentation.
> >
> > Here we have the culprit:
> > $> make CFLAGS=-DMSC_TEST test
> > ...
> > Loaded 8 tests from ./op/rx.t
> > 1) op "rx": passed (Pattern match "" at UNIT_TEST.)
> > 2) op "rx": passed
> > 3) op "rx": passed (Pattern match "" at UNIT_TEST.)
> > 4) op "rx": passed (Pattern match "abc" at UNIT_TEST.)
> > 5) op "rx": passed (Pattern match "def" at UNIT_TEST.)
> > 6) op "rx": passed (Pattern match "ghi" at UNIT_TEST.)
> > 7) op "rx": passed
> > ERROR: Failed to create rule for op "rx": Error creating rule: Error
> compiling pattern (offset 2): unrecognized character after (? or (?-
> > Test exited with signal 11.
> > Executed: ./msc_test "-t" "op" "-n" "rx" "-p"
> "(?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)" "-D" "0" "-r" "1"
> > 8) op "rx": failed
> > Passed: 7; Failed: 1
> > ...
> > 576/577 tests passed.
> > FAIL: run-unit-tests.pl
> > ========================================
> > 1 of 1 test failed
> > Please report to su...@mo...
> > ========================================
> > make[2]: *** [check-TESTS] Error 1
> > make[2]: Leaving directory
> `/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests'
> > make[1]: *** [check-am] Error 2
> > make[1]: Leaving directory
> `/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests'
> > make: *** [check-recursive] Error 1
>
> I was curious why this didn't fail for me. I vaguely remember other
> users had reported the same problem before. So here's what I think is
> the explanation:
>
> The original pattern in the unit test is in op/rx.t:
>
> qr/^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$/i
>
> The pattern is read by the perl script run-unit-tests.pl. Before Perl
> 5.14 the qr was converted to:
>
> (?i-xsm:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)
>
> Starting with Perl 5.14 there's a new syntax and the pattern results in
>
> (?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)
>
> (See e.g. http://perldoc.perl.org/perlre.html#Extended-Patterns, there
> look for "Starting in Perl 5.14").
>
> Now the unit tests feed the internal representation to the compiled
> msc_test binary, which calls the PCRE library to handle the regexp.
> Unfortunately the PCRE library only accepts the old way of expressing
> this pattern, not the new ?^ syntax.
>
> So if you run the unit tests with a Perl before 5.14 they succeed, with
> a newer Perl they fail, because a Perl pre-compiled pattern might no
> longer be compatible with PCRE (despite what PCRE means).
>
> I didn't find a bug report for the missing ?^ syntax in the PCRE bug
> tracker, but "?^" is not the best token to start a search with.
>
> Regards,
>
> Rainer
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
>
|
|
From: Christian F. <chr...@ti...> - 2013-07-16 20:52:35
|
You rock, Rainer.
And you hit the nail on the head:
$> dpkg -l | grep perl
...
ii perl 5.14.2-6ubuntu2.3 ...
...
Cheers,
Christian
On Tue, Jul 16, 2013 at 10:15:31PM +0200, Rainer Jung wrote:
> On 16.07.2013 21:05, Christian Folini wrote:
> > Hello Rainer,
> >
> > On Tue, Jul 16, 2013 at 01:05:08PM +0200, Rainer Jung wrote:
> >> Hi Christian,
> >>
> >> I think when running the unit tests via "make test" you should add
> >> -DMSC_TEST to CFLAGS. That flag comments all httpd calls and produces
> >> standalone binaries.
> >
> > Thanks for the info. True, it's mentioned in the reference guide.
> > It's just that I used outdated documentation.
> >
> > Here we have the culprit:
> > $> make CFLAGS=-DMSC_TEST test
> > ...
> > Loaded 8 tests from ./op/rx.t
> > 1) op "rx": passed (Pattern match "" at UNIT_TEST.)
> > 2) op "rx": passed
> > 3) op "rx": passed (Pattern match "" at UNIT_TEST.)
> > 4) op "rx": passed (Pattern match "abc" at UNIT_TEST.)
> > 5) op "rx": passed (Pattern match "def" at UNIT_TEST.)
> > 6) op "rx": passed (Pattern match "ghi" at UNIT_TEST.)
> > 7) op "rx": passed
> > ERROR: Failed to create rule for op "rx": Error creating rule: Error compiling pattern (offset 2): unrecognized character after (? or (?-
> > Test exited with signal 11.
> > Executed: ./msc_test "-t" "op" "-n" "rx" "-p" "(?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)" "-D" "0" "-r" "1"
> > 8) op "rx": failed
> > Passed: 7; Failed: 1
> > ...
> > 576/577 tests passed.
> > FAIL: run-unit-tests.pl
> > ========================================
> > 1 of 1 test failed
> > Please report to su...@mo...
> > ========================================
> > make[2]: *** [check-TESTS] Error 1
> > make[2]: Leaving directory `/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests'
> > make[1]: *** [check-am] Error 2
> > make[1]: Leaving directory `/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests'
> > make: *** [check-recursive] Error 1
>
> I was curious why this didn't fail for me. I vaguely remember other
> users had reported the same problem before. So here's what I think is
> the explanation:
>
> The original pattern in the unit test is in op/rx.t:
>
> qr/^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$/i
>
> The pattern is read by the perl script run-unit-tests.pl. Before Perl
> 5.14 the qr was converted to:
>
> (?i-xsm:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)
>
> Starting with Perl 5.14 there's a new syntax and the pattern results in
>
> (?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)
>
> (See e.g. http://perldoc.perl.org/perlre.html#Extended-Patterns, there
> look for "Starting in Perl 5.14").
>
> Now the unit tests feed the internal representation to the compiled
> msc_test binary, which calls the PCRE library to handle the regexp.
> Unfortunately the PCRE library only accepts the old way of expressing
> this pattern, not the new ?^ syntax.
>
> So if you run the unit tests with a Perl before 5.14 they succeed, with
> a newer Perl they fail, because a Perl pre-compiled pattern might no
> longer be compatible with PCRE (despite what PCRE means).
>
> I didn't find a bug report for the missing ?^ syntax in the PCRE bug
> tracker, but "?^" is not the best token to start a search with.
>
> Regards,
>
> Rainer
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
|
|
From: Breno S. <bre...@gm...> - 2013-07-18 15:22:35
|
Hello guys, I updated the code with some fixes. Then created a tarball for testing. Hope those are the latest modifications: https://www.modsecurity.org/tarball/2.7.5/modsecurity-apache_2.7.5.tar.gz Let me known your feedback. Thanks Breno On Tue, Jul 16, 2013 at 5:52 PM, Christian Folini < chr...@ti...> wrote: > You rock, Rainer. > > And you hit the nail on the head: > > $> dpkg -l | grep perl > ... > ii perl 5.14.2-6ubuntu2.3 ... > ... > > Cheers, > > Christian > > > On Tue, Jul 16, 2013 at 10:15:31PM +0200, Rainer Jung wrote: > > On 16.07.2013 21:05, Christian Folini wrote: > > > Hello Rainer, > > > > > > On Tue, Jul 16, 2013 at 01:05:08PM +0200, Rainer Jung wrote: > > >> Hi Christian, > > >> > > >> I think when running the unit tests via "make test" you should add > > >> -DMSC_TEST to CFLAGS. That flag comments all httpd calls and produces > > >> standalone binaries. > > > > > > Thanks for the info. True, it's mentioned in the reference guide. > > > It's just that I used outdated documentation. > > > > > > Here we have the culprit: > > > $> make CFLAGS=-DMSC_TEST test > > > ... > > > Loaded 8 tests from ./op/rx.t > > > 1) op "rx": passed (Pattern match "" at UNIT_TEST.) > > > 2) op "rx": passed > > > 3) op "rx": passed (Pattern match "" at UNIT_TEST.) > > > 4) op "rx": passed (Pattern match "abc" at UNIT_TEST.) > > > 5) op "rx": passed (Pattern match "def" at UNIT_TEST.) > > > 6) op "rx": passed (Pattern match "ghi" at UNIT_TEST.) > > > 7) op "rx": passed > > > ERROR: Failed to create rule for op "rx": Error creating rule: Error > compiling pattern (offset 2): unrecognized character after (? or (?- > > > Test exited with signal 11. > > > Executed: ./msc_test "-t" "op" "-n" "rx" "-p" > "(?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)" "-D" "0" "-r" "1" > > > 8) op "rx": failed > > > Passed: 7; Failed: 1 > > > ... > > > 576/577 tests passed. > > > FAIL: run-unit-tests.pl > > > ======================================== > > > 1 of 1 test failed > > > Please report to su...@mo... > > > ======================================== > > > make[2]: *** [check-TESTS] Error 1 > > > make[2]: Leaving directory > `/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests' > > > make[1]: *** [check-am] Error 2 > > > make[1]: Leaving directory > `/usr/src/modsecurity/ModSecurity-remotes-2.7.x/tests' > > > make: *** [check-recursive] Error 1 > > > > I was curious why this didn't fail for me. I vaguely remember other > > users had reported the same problem before. So here's what I think is > > the explanation: > > > > The original pattern in the unit test is in op/rx.t: > > > > qr/^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$/i > > > > The pattern is read by the perl script run-unit-tests.pl. Before Perl > > 5.14 the qr was converted to: > > > > (?i-xsm:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$) > > > > Starting with Perl 5.14 there's a new syntax and the pattern results in > > > > (?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$) > > > > (See e.g. http://perldoc.perl.org/perlre.html#Extended-Patterns, there > > look for "Starting in Perl 5.14"). > > > > Now the unit tests feed the internal representation to the compiled > > msc_test binary, which calls the PCRE library to handle the regexp. > > Unfortunately the PCRE library only accepts the old way of expressing > > this pattern, not the new ?^ syntax. > > > > So if you run the unit tests with a Perl before 5.14 they succeed, with > > a newer Perl they fail, because a Perl pre-compiled pattern might no > > longer be compatible with PCRE (despite what PCRE means). > > > > I didn't find a bug report for the missing ?^ syntax in the PCRE bug > > tracker, but "?^" is not the best token to start a search with. > > > > Regards, > > > > Rainer > > > > > ------------------------------------------------------------------------------ > > See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > _______________________________________________ > > mod-security-developers mailing list > > mod...@li... > > https://lists.sourceforge.net/lists/listinfo/mod-security-developers > > ModSecurity Services from Trustwave's SpiderLabs: > > https://www.trustwave.com/spiderLabs.php > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > mod-security-developers mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-developers > ModSecurity Services from Trustwave's SpiderLabs: > https://www.trustwave.com/spiderLabs.php > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X