Re: [RELEASE CANDIDATE] mod_perl-2.0.11 RC2

2019-09-26 Thread Steve Hay 
On Thu, 26 Sep 2019 at 16:17, Damyan Ivanov  wrote:
>
> -=| Steve Hay, 26.09.2019 09:02:19 +0100 |=-
> > Before I actually roll out an RC3, please can you confirm that
> > switching to FINFO_SIZE as per this patch works for you (it does for
> > me):
> > …
>
> This works for me:
>
> # testing : $r->finfo
> # expected: 7278
> # received: 7278
> ok 44
>
> (the rest of the tests still pass).
>

Thanks for the confirmation. RC3 is now uploaded.

-
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org

Re: [RELEASE CANDIDATE] mod_perl-2.0.11 RC2

2019-09-26 Thread Damyan Ivanov 
-=| Steve Hay, 26.09.2019 09:02:19 +0100 |=-
> Before I actually roll out an RC3, please can you confirm that
> switching to FINFO_SIZE as per this patch works for you (it does for
> me):
> …

This works for me:

# testing : $r->finfo
# expected: 7278
# received: 7278
ok 44

(the rest of the tests still pass).

-- Damyan


-
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org

Re: [RELEASE CANDIDATE] mod_perl-2.0.11 RC2

2019-09-26 Thread Steve Hay 
On Thu, 26 Sep 2019 at 06:54, Damyan Ivanov  wrote:
>
> -=| Damyan Ivanov, 25.09.2019 23:06:56 +0300 |=-
> > -=| Steve Hay, 25.09.2019 08:34:07 +0100 |=-
> > > What happens if you revert the change in that file? I.e. Change
> > > FINFO_NAME back to FINFO_NORM on line 168, and on line 18 (the
> > > APR::Const -compile line)? Does that fix it for you?
> >
> > With these two lines reverted, all tests pass for me.
>
> Out of interest I also tried using "FINFO_NAME | FINFO_NORM" on line
> 168 and the test failed with the same error. It appears that
> FINFO_NAME triggers it.
>
> Tracing this in APR, the error seems to come from
> file_io/unix/filestat.c¹ where the valid flags on line 73 don't
> include APR_FINFO_NAME. This kind of makes sense, because the stat(2)
> struct lacks information about the file name.
>
>  ¹ https://sources.debian.org/src/apr/1.6.5-1/file_io/unix/filestat.c/
>
> -- Damyan

Good catch! That explains why using FINFO_NAME is failing for you but
working for me (on Windows): apr/file_io/win32/filestat.c *does* have
support for FINFO_NAME in it, filling in finfo->name from filename if
it succeeded in getting filename (using calls other than stat()!).

The point of the request_rec test in question is only to test a single
field anyway (the rest are tested in TestAPR::finfo, as the comment
says) so I will simply change it to test a different field. Evidently
FINFO_NAME was a poor choice!

Before I actually roll out an RC3, please can you confirm that
switching to FINFO_SIZE as per this patch works for you (it does for
me):

Index: t/response/TestAPI/request_rec.pm
===
--- t/response/TestAPI/request_rec.pm (revision 1866274)
+++ t/response/TestAPI/request_rec.pm (working copy)
@@ -15,7 +15,7 @@
 use APR::Pool ();

 use Apache2::Const -compile => qw(OK M_GET M_PUT);
-use APR::Const-compile => qw(FINFO_NAME);
+use APR::Const-compile => qw(FINFO_SIZE);

 #this test module is only for testing fields in the request_rec
 #listed in apache_structures.map
@@ -165,12 +165,13 @@

 # finfo
 {
-my $finfo = APR::Finfo::stat(__FILE__,
APR::Const::FINFO_NAME, $r->pool);
+my $size = (stat __FILE__)[7];
+my $finfo = APR::Finfo::stat(__FILE__,
APR::Const::FINFO_SIZE, $r->pool);
 $r->finfo($finfo);
 # just one field test, all accessors are fully tested in
 # TestAPR::finfo
-ok t_cmp($r->finfo->fname,
- __FILE__,
+ok t_cmp($r->finfo->size,
+ $size,
  '$r->finfo');
 }


request_rec.patch
Description: Binary data

-
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org

Re: [RELEASE CANDIDATE] mod_perl-2.0.11 RC2

2019-09-25 Thread Damyan Ivanov 
-=| Damyan Ivanov, 25.09.2019 23:06:56 +0300 |=-
> -=| Steve Hay, 25.09.2019 08:34:07 +0100 |=-
> > What happens if you revert the change in that file? I.e. Change
> > FINFO_NAME back to FINFO_NORM on line 168, and on line 18 (the
> > APR::Const -compile line)? Does that fix it for you?
> 
> With these two lines reverted, all tests pass for me.

Out of interest I also tried using "FINFO_NAME | FINFO_NORM" on line 
168 and the test failed with the same error. It appears that 
FINFO_NAME triggers it.

Tracing this in APR, the error seems to come from 
file_io/unix/filestat.c¹ where the valid flags on line 73 don't 
include APR_FINFO_NAME. This kind of makes sense, because the stat(2) 
struct lacks information about the file name.

 ¹ https://sources.debian.org/src/apr/1.6.5-1/file_io/unix/filestat.c/

-- Damyan

-
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org

Re: [RELEASE CANDIDATE] mod_perl-2.0.11 RC2

2019-09-25 Thread Adam Prime 


What happens if you revert the change in that file? I.e. Change
FINFO_NAME back to FINFO_NORM on line 168, and on line 18 (the
APR::Const -compile line)? Does that fix it for you?



With that change all the request_rec tests run and pass.

Adam

-
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org

Re: [RELEASE CANDIDATE] mod_perl-2.0.11 RC2

2019-09-25 Thread Damyan Ivanov 
-=| Steve Hay, 25.09.2019 08:34:07 +0100 |=-
> What happens if you revert the change in that file? I.e. Change
> FINFO_NAME back to FINFO_NORM on line 168, and on line 18 (the
> APR::Const -compile line)? Does that fix it for you?

With these two lines reverted, all tests pass for me (and the Debian 
package finished building. Yay!).


-- Damyan

-
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org

Re: [RELEASE CANDIDATE] mod_perl-2.0.11 RC2

2019-09-25 Thread Steve Hay 
On Wed, 25 Sep 2019 at 03:59, Adam Prime  wrote:
>
> Still seeing the t/api/request_rec.t failures, which do not occur with
> the same machine and same settings with 2.0.10. It's failing after the
> mtime test, before the finfo test.
>
> Test Summary Report
> ---
> t/api/request_rec.t   (Wstat: 0 Tests: 43 Failed: 0)
>Parse errors: Bad plan.  You planned 55 tests but ran 43.
> t/filter/in_bbs_inject_header.t   (Wstat: 0 Tests: 36 Failed: 3)
>Failed tests:  22, 26, 30
> Files=245, Tests=3402, 98 wallclock secs ( 0.71 usr  0.30 sys + 67.05
> cusr 12.05 csys = 80.11 CPU)
> Result: FAIL
> Failed 2/245 test programs. 3/3402 subtests failed.
>
>

(Btw, the filter/in_bbs_inject_header.t failures are an existing
problem - see https://rt.cpan.org/Ticket/Display.html?id=118919)

-
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org

Re: [RELEASE CANDIDATE] mod_perl-2.0.11 RC2

2019-09-25 Thread Steve Hay 
On Wed, 25 Sep 2019 at 03:59, Adam Prime  wrote:
>
> Still seeing the t/api/request_rec.t failures, which do not occur with
> the same machine and same settings with 2.0.10. It's failing after the
> mtime test, before the finfo test.
>
> Test Summary Report
> ---
> t/api/request_rec.t   (Wstat: 0 Tests: 43 Failed: 0)
>Parse errors: Bad plan.  You planned 55 tests but ran 43.
> t/filter/in_bbs_inject_header.t   (Wstat: 0 Tests: 36 Failed: 3)
>Failed tests:  22, 26, 30
> Files=245, Tests=3402, 98 wallclock secs ( 0.71 usr  0.30 sys + 67.05
> cusr 12.05 csys = 80.11 CPU)
> Result: FAIL
> Failed 2/245 test programs. 3/3402 subtests failed.
>
>
> This is what i see in the error_log:
>
> [Tue Sep 24 22:56:10.012601 2019] [perl:error] [pid 743] [client
> 127.0.0.1:57720] APR::Finfo::stat: (70008) Partial results are valid but
> processing is incomplete at
> /tmp/mod_perl-2.0.11-rc2/t/response/TestAPI/request_rec.pm line 168
>
> Not sure if this is a concern or not, but it seems like it should be?
>

Yes, it's definitely a concern! We have two reports of exactly the
same failure now - this and the one from Damyan Ivanov.

This is exactly the kind of problem that I was getting with libapr's
apr_stat() function (see
https://bz.apache.org/bugzilla/show_bug.cgi?id=51560), which I fixed
for Windows in rev. 1865449. As noted before I do see various test
failures on Windows, but none relating to apr_stat() now, and I don't
get any api/request_rec.t failure at all.

This seems to imply either that other OSes are getting similar
problems that need working around similarly to Windows, or else that
the Windows fixes I've applied have broken other OSes. In this case
I'm wondering if it might the latter:-

The rev. cited above changed exactly the line that the failure is
reported on - line 168 in t/response/TestAPI/request_rec.pm... I
changed FINFO_NORM to FINFO_NAME since it's only fname that we access
so we shouldn't need all the other fields. (Windows has a problem
getting all the fields (specifically, it often fails on the
APR_FINFO_GPROT and APR_FINFO_WPROT bits) so that change dodged the
problem for me.)

What happens if you revert the change in that file? I.e. Change
FINFO_NAME back to FINFO_NORM on line 168, and on line 18 (the
APR::Const -compile line)? Does that fix it for you?

-
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org

Re: [RELEASE CANDIDATE] mod_perl-2.0.11 RC2

2019-09-24 Thread Adam Prime 
Still seeing the t/api/request_rec.t failures, which do not occur with 
the same machine and same settings with 2.0.10. It's failing after the 
mtime test, before the finfo test.


Test Summary Report
---
t/api/request_rec.t   (Wstat: 0 Tests: 43 Failed: 0)
  Parse errors: Bad plan.  You planned 55 tests but ran 43.
t/filter/in_bbs_inject_header.t   (Wstat: 0 Tests: 36 Failed: 3)
  Failed tests:  22, 26, 30
Files=245, Tests=3402, 98 wallclock secs ( 0.71 usr  0.30 sys + 67.05 
cusr 12.05 csys = 80.11 CPU)

Result: FAIL
Failed 2/245 test programs. 3/3402 subtests failed.


This is what i see in the error_log:

[Tue Sep 24 22:56:10.012601 2019] [perl:error] [pid 743] [client 
127.0.0.1:57720] APR::Finfo::stat: (70008) Partial results are valid but 
processing is incomplete at 
/tmp/mod_perl-2.0.11-rc2/t/response/TestAPI/request_rec.pm line 168


Not sure if this is a concern or not, but it seems like it should be?

Adam


On 9/24/19 12:53 PM, Steve Hay wrote:

Please download, test, and report back on this mod_perl 2.0.11 release
candidate.

https://dist.apache.org/repos/dist/dev/perl/mod_perl-2.0.11-rc2.tar.gz

MD5  = abc2c2168121a09b0fc3b6fc6adc00bd
SHA1 = 36ee7626506a3a461118b3957814dfe9331ef1de

Changes since RC1 are as follows:

Fix [CVE-2011-2767] Arbitrary Perl code execution in the context of the user
account via a user-owned .htaccess. Patch from bugs.debian.org #644169. [Jan
Ingvoldstad ]

Fix potential test suite hangs due to pipelined response deadlocks. Patch
from rt.cpan.org #82409. [Zefram ]

Fix t/compat/request.t failures [Steve Hay]



-
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org

Re: [RELEASE CANDIDATE] mod_perl-2.0.11 RC2

2019-09-24 Thread Damyan Ivanov 
(Cc-ing Debian Perl group in case I missed something obvious)

-=| Steve Hay, 24.09.2019 17:53:14 +0100 |=-
> Please download, test, and report back on this mod_perl 2.0.11 release
> candidate.
> 
> https://dist.apache.org/repos/dist/dev/perl/mod_perl-2.0.11-rc2.tar.gz

One test fails on Debian unstable/amd64.

-8<-- Start Bug Report 8<--
1. Problem Description:

…
# testing : mtime
# expected: 1569347574
# received: '1569347574'
ok 43


500 Internal Server Error

Internal Server Error
The server encountered an internal error or
misconfiguration and was unable to complete
your request.
Please contact the server administrator at 
 dam@localhost to inform them of the time this error occurred,
 and the actions you performed just before this error.
More information about this error may be available
in the server error log.

Apache/2.4.41 (Debian) world domination series/2.0 
mod_apreq2-20090110/2.8.0 mod_perl/2.0.11-rc2 Perl/v5.28.1 Server at localhost 
Port 8529

Failed 12/55 subtests 

Test Summary Report
---
t/api/request_rec.t (Wstat: 0 Tests: 43 Failed: 0)
  Parse errors: Bad plan.  You planned 55 tests but ran 43.
Files=1, Tests=43,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.46 cusr  0.13 
csys =  0.61 CPU)
Result: FAIL

error_log:
(full log for request_rec.t attached)

[Tue Sep 24 21:55:53.589476 2019] [perl:error] [pid 1184:tid 140271230908160] 
[client 127.0.0.1:40218] APR::Finfo::stat: (70008) Partial results are valid 
but processing is incomplete at 
/home/dam/w/pkg-perl/packages/libapache2-mod-perl2/t/response/TestAPI/request_rec.pm
 line 168

Note that in Debian apache, apreq and mod_perl have plenty of patches 
applied. That wasn't a problem by itself before, but I'd rather 
mention it here to avoid surprises.

This report is about the RC2 tarball with all the patches at 
https://salsa.debian.org/perl-team/modules/packages/libapache2-mod-perl2/tree/master/debian/patches
 
minus
 260_fix_pipelined_response_deadlock.patch,
 370_http_syntax.patch,
 380_inject_header_line_terminators.patch, and
 CVE-2011-2767.patch
that were included in this RC2 release (thanks!)

2. Used Components and their Configuration:

*** mod_perl version 2.11

*** using 
/home/dam/w/pkg-perl/packages/libapache2-mod-perl2/lib/Apache2/BuildConfig.pm

*** Makefile.PL options:
  MP_APR_CONFIG  => /usr/bin/apr-config
  MP_APR_LIB => aprext
  MP_APXS=> /usr/bin/apxs
  MP_CCOPTS  => -g -O2 
-fdebug-prefix-map=/home/dam/w/pkg-perl/packages/libapache2-mod-perl2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -fgnu89-inline
  MP_COMPAT_1X   => 1
  MP_GENERATE_XS => 1
  MP_LIBNAME => mod_perl
  MP_TRACE   => 0
  MP_USE_DSO => 1
  MP_USE_STATIC  => 0


*** /usr/sbin/apache2 -V
Server version: Apache/2.4.41 (Debian)
Server built:   2019-08-14T04:42:29
Server's Module Magic Number: 20120211:88
Server loaded:  APR 1.6.5, APR-UTIL 1.6.1
Compiled using: APR 1.6.5, APR-UTIL 1.6.1
Architecture:   64-bit
Server MPM: 
Server compiled with
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/apache2"
 -D SUEXEC_BIN="/usr/lib/apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/apache2.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="mime.types"
 -D SERVER_CONFIG_FILE="apache2.conf"

*** /usr/bin/ldd /usr/sbin/apache2
linux-vdso.so.1 (0x7ffc791c9000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f145fe89000)
libaprutil-1.so.0 => /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0 
(0x7f145fe5b000)
libapr-1.so.0 => /usr/lib/x86_64-linux-gnu/libapr-1.so.0 
(0x7f145fe22000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f145fe01000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f145fc41000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f145fc38000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f145fc2b000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 
(0x7f145fbf2000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f145fbed000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 
(0x7f145fbc)
/lib64/ld-linux-x86-64.so.2 (0x7f145ffcc000)


*** (apr|apu)-config linking info

 -L/usr/lib/x86_64-linux-gnu -laprutil-1
 -L/usr/lib/x86_64-linux-gnu -lapr-1  



*** /usr/bin/perl -V
Summary of my perl5 (revision 5 version 28 subversion 1) configuration:
   
  Platform:
osname=linux
osvers=4.9.0
archname=x86_64-linux-gnu-thread-multi
uname='linux localhost 4.9.0 #1 smp debian 4.9.0 x86_64 gnulinux '
config_args='-Dusethreads