You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Daniel Ruggeri <dr...@primary.net> on 2018/10/18 14:36:41 UTC
[VOTE] Release httpd-2.4.37
Hi, all;
Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/
I would like to call a VOTE over the next few days to release this
candidate tarball as 2.4.37:
[ ] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.
The computed digests of the tarball up for vote are:
sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
sha256: aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
*httpd-2.4.37.tar.gz
--
Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.37
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1:
o macOS 10.13.6, Xcode 10, OpenSSL 1.1.1 and 1.0.2p
o CentOS 5&6, OpenSSL 1.0.2, 64bit
Thx for RMing!
> On Oct 18, 2018, at 10:36 AM, Daniel Ruggeri <DR...@primary.net> wrote:
>
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this candidate tarball as 2.4.37:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
> sha256: aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd *httpd-2.4.37.tar.gz
>
> --
> Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.37
Posted by Stefan Eissing <st...@greenbytes.de>.
+1
MacOS 10.14, OpenSSL 1.0.2p + 1.1.1, mod-h2 suite, mod-md suite
Ubuntu 18.04 LTS, OpenSSL 1.1.0h, mod-h2 suite
Thanks for RM'ing, Daniel!
> Am 18.10.2018 um 16:36 schrieb Daniel Ruggeri <dr...@primary.net>:
>
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this candidate tarball as 2.4.37:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
> sha256: aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd *httpd-2.4.37.tar.gz
>
> --
> Daniel Ruggeri
Re: httpd and php integration
Posted by Dennis Clarke <dc...@blastwave.org>.
On 10/18/2018 07:29 PM, Rainer Jung wrote:
> Am 19.10.2018 um 00:46 schrieb Dennis Clarke:
>> On 10/18/2018 04:57 PM, Rainer Jung wrote:
>>> Am 18.10.2018 um 21:55 schrieb Dennis Clarke:
>>> You debugger output shows jump = 0x101e2915c. This address is not
>>> divisible by 8, so it seems it confirms the alignment problem.
>>>
>>
>> 0x101e2915c ??
>>
>
> I'm referring to https://bugs.php.net/bug.php?id=76745 and the line:
>
ah .. I was wondering where you saw that address ... I was looking at my
xterm :-\
> ...
> t@1 (l@1) program terminated by signal BUS (invalid address alignment)
> Current function is set_jump
> 641 jump->next = NULL;
> (dbx) where
> current thread: t@1
> =>[1] set_jump(jump = 0x101e2915c, compiler = 0x101e280b0, flags = 0),
> line 641 in "sljitLir.c"
> ^^^^^^^^^^^^^^^^^^^^^^0x101e2915c^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> [2] sljit_emit_jump(compiler = 0x101e280b0, type = 24), line 1320 in
> "sljitNativeSPARC_common.c"
> [3] mainloop_entry(common = 0xffffffff7fffd180, hascrorlf = 0), line
> 3372 in "pcre_jit_compile.c"
> ...
Right.
I will circle back around on this after I see httpd 2.4.37/38/39 built
and running. Don't be surprised if I may have questions and more
odd things. I see a bootstrap of gcc happening tonight.
Dennis
Re: httpd and php integration
Posted by Rainer Jung <ra...@kippdata.de>.
Am 19.10.2018 um 00:46 schrieb Dennis Clarke:
> On 10/18/2018 04:57 PM, Rainer Jung wrote:
>> Am 18.10.2018 um 21:55 schrieb Dennis Clarke:
>> You debugger output shows jump = 0x101e2915c. This address is not
>> divisible by 8, so it seems it confirms the alignment problem.
>>
>
> 0x101e2915c ??
>
> Not sure where you are seeing that but .. I am going back to start over
> with some updates and possibly a new gcc bootstrap and pcre and whatever
> else I can throw at the wall here. Really the Apache 2.4.37 ( today 37
> and tomorrow 38? ) is what I am aiming for.
I'm referring to https://bugs.php.net/bug.php?id=76745 and the line:
...
t@1 (l@1) program terminated by signal BUS (invalid address alignment)
Current function is set_jump
641 jump->next = NULL;
(dbx) where
current thread: t@1
=>[1] set_jump(jump = 0x101e2915c, compiler = 0x101e280b0, flags = 0),
line 641 in "sljitLir.c"
^^^^^^^^^^^^^^^^^^^^^^0x101e2915c^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[2] sljit_emit_jump(compiler = 0x101e280b0, type = 24), line 1320 in
"sljitNativeSPARC_common.c"
[3] mainloop_entry(common = 0xffffffff7fffd180, hascrorlf = 0), line
3372 in "pcre_jit_compile.c"
...
Regards,
Rainer
Re: httpd and php integration
Posted by Dennis Clarke <dc...@blastwave.org>.
On 10/18/2018 04:57 PM, Rainer Jung wrote:
> Am 18.10.2018 um 21:55 schrieb Dennis Clarke:
>> On 10/18/2018 03:42 PM, Rainer Jung wrote:
>>> Am 18.10.2018 um 21:18 schrieb Dennis Clarke:
>>>> On 10/18/2018 02:12 PM, Daniel Ruggeri wrote:
>>>>> php: "5.6.38"
>>>>
>>
>>> I do build PHP 7.x myself including recent library versions both on
>>> some Linux platforms as well as on Solaris Sparc. But the typical use
>>> is via PHP-FPM, not mod_php. So httpd integration is done via
>>> mod_proxy_fcgi which is part of httpd nowadays. I do not test PHP
>>> with the httpd test suite, only with the tests that come with PHP
>>> itself.
>>
>> Yes, I see the php-fpm approach and ye old mod_php was fine for php 5.x
>> world but the world has moved onwards.
>>
>>> When running the test suite I typically get about 50-80 test failures
>>> on Linux and 150-200 test failures on Solaris (of about 13000
>>> non-skipped tests).
>>
>> I get outright SIGBUS core dump :-(
>
> Yes, I sometimes get them and try to get them analyzed (by myself) and
> fixed (by the PHP people). On Solaris Sparc the SIGBUS almost always
> comes from bad alignment, where an 8 byte type is not located at an
> address divisible by 8. X86_64 is not sensible to this and of course the
> PHP people do not typically test on Sparc.
*nod*
> Concerning the 7.2.8 failure: the biggest difference between our setups
> is probably the compiler. I wanted to keep deltas to the mostly used
> platform Linux small, so I build using GCC (which I compile myself).
You and I seem to be the last people still bootstrapping gcc on Solaris
sparc but that is another discussion on another maillist ;-)
> The
> alignment in question could well be sensible to the compiler used.
> Furthermore I am doing still 32 bit builds, and it looks like you are
> doing 64 bit builds.
Pure 64-bit has been my way for almost the last decade. I think I waved
farewell to Solaris 8 back in 2008 and that resulted in a near revolt
within "Blastwave" because, well, money. That is an old story. Also we
all thought OpenSolaris was going to change the landscape. Another old
story. However my 64-bit stack has been the floor plan stuff that kept
a small finance company running production software for many years and
that included recent Apache httpd and php and the usual stuff needed for
Wordpress sites and a lot of custom internal stuff. Gets more difficult
every day to deal with updates however and here we are looking at httpd
with tls 1.3 and with httpd ver 2.4.37. All good stuff to be sure.
>
> Looking at your issue
>
> https://bugs.php.net/bug.php?id=76745
>
> I did not myself observe this problem. It looks like a pcre problem,
I was thinking the same and built my own.
beta $ file /usr/local/bin/pcretest
/usr/local/bin/pcretest: ELF 64-bit MSB executable SPARCV9 Version 1,
UltraSPARC3 Extensions Required, dynamically linked, not stripped
beta $
beta $ /usr/local/bin/pcretest -C
PCRE version 8.40 2017-01-11
Compiled with
8-bit support
UTF-8 support
16-bit support
UTF-16 support
32-bit support
UTF-32 support
Unicode properties support
No just-in-time compiler support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 4
POSIX malloc threshold = 10
Parentheses nest limit = 250
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses heap
beta $
Works very very well. So I am surprised at the alignment. In fact I have
*had* it running neatly for a while. I often wondered what that internal
link size really means ... hrmmm .. 4 ? 32-bit? Could be a red herring.
> not
> really a PHP problem. The pcre they bundle in 7.2.8 is version 8.41.
> Recent for 8.x would be 8.42, but even in 7.2.11 it is still at 8.41. On
> the other hand, I did not find an immediate information, that 8.42 fixes
> an alignment problem in the jit. But it does contain quite a few jit
> changes.
OKay .. I am going back to the source well and perhaps bootstrap GCC 8.x
again and why not? It has been a over a month since I looked.
> You debugger output shows jump = 0x101e2915c. This address is not
> divisible by 8, so it seems it confirms the alignment problem.
>
0x101e2915c ??
Not sure where you are seeing that but .. I am going back to start over
with some updates and possibly a new gcc bootstrap and pcre and whatever
else I can throw at the wall here. Really the Apache 2.4.37 ( today 37
and tomorrow 38? ) is what I am aiming for.
> You could try to reproduce the problem by compiling pcre 8.41 standalone
> and run the pcre test suite.
Yep. That first.
> Uf you can reproduce, you can check,
> whether it is goine in 8.42 and then at least point the php people to
> that finding, asking them for an upgrade. Finally you can also try to
> add pcre 8.42 into your php source tree under ext/pcre/pcrelib.
I may do both. Actually ... now that I think on it.
> It seems
> PHP does not change any of the files, but you would also need to add the
> generated files config.h, pcre_chartables.c and pcre.h. You can probably
> get those by first running configure and maybe also make for a
> standalone pcre 8.42.
All good thinking ... thank you.
>
> Concerning your foo.php script, I get the same results, but it starts
> working when using INPUT_ENV. I don't know what the definition of
> INPUT_SERVER for PHP CLI is. At least for PHP with FCGI it seems to be
> known that INPUT_SERVER doesn't work well. So probably not something
> specific to your build.
Not worth digging into. For now. That would be like moving around the
deck chairs on the Titanic.
Thank you Rainer.
Dennis Clarke
Re: httpd and php integration
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.10.2018 um 21:55 schrieb Dennis Clarke:
> On 10/18/2018 03:42 PM, Rainer Jung wrote:
>> Am 18.10.2018 um 21:18 schrieb Dennis Clarke:
>>> On 10/18/2018 02:12 PM, Daniel Ruggeri wrote:
>>>> php: "5.6.38"
>>>
>
>> I do build PHP 7.x myself including recent library versions both on
>> some Linux platforms as well as on Solaris Sparc. But the typical use
>> is via PHP-FPM, not mod_php. So httpd integration is done via
>> mod_proxy_fcgi which is part of httpd nowadays. I do not test PHP with
>> the httpd test suite, only with the tests that come with PHP itself.
>
> Yes, I see the php-fpm approach and ye old mod_php was fine for php 5.x
> world but the world has moved onwards.
>
>> When running the test suite I typically get about 50-80 test failures
>> on Linux and 150-200 test failures on Solaris (of about 13000
>> non-skipped tests).
>
> I get outright SIGBUS core dump :-(
Yes, I sometimes get them and try to get them analyzed (by myself) and
fixed (by the PHP people). On Solaris Sparc the SIGBUS almost always
comes from bad alignment, where an 8 byte type is not located at an
address divisible by 8. X86_64 is not sensible to this and of course the
PHP people do not typically test on Sparc.
Concerning the 7.2.8 failure: the biggest difference between our setups
is probably the compiler. I wanted to keep deltas to the mostly used
platform Linux small, so I build using GCC (which I compile myself). The
alignment in question could well be sensible to the compiler used.
Furthermore I am doing still 32 bit builds, and it looks like you are
doing 64 bit builds.
Looking at your issue
https://bugs.php.net/bug.php?id=76745
I did not myself observe this problem. It looks like a pcre problem, not
really a PHP problem. The pcre they bundle in 7.2.8 is version 8.41.
Recent for 8.x would be 8.42, but even in 7.2.11 it is still at 8.41. On
the other hand, I did not find an immediate information, that 8.42 fixes
an alignment problem in the jit. But it does contain quite a few jit
changes.
You debugger output shows jump = 0x101e2915c. This address is not
divisible by 8, so it seems it confirms the alignment problem.
You could try to reproduce the problem by compiling pcre 8.41 standalone
and run the pcre test suite. Uf you can reproduce, you can check,
whether it is goine in 8.42 and then at least point the php people to
that finding, asking them for an upgrade. Finally you can also try to
add pcre 8.42 into your php source tree under ext/pcre/pcrelib. It seems
PHP does not change any of the files, but you would also need to add the
generated files config.h, pcre_chartables.c and pcre.h. You can probably
get those by first running configure and maybe also make for a
standalone pcre 8.42.
Concerning your foo.php script, I get the same results, but it starts
working when using INPUT_ENV. I don't know what the definition of
INPUT_SERVER for PHP CLI is. At least for PHP with FCGI it seems to be
known that INPUT_SERVER doesn't work well. So probably not something
specific to your build.
Regards,
Rainer
> beta $ TEST_PHP_EXECUTABLE=sapi/cli/php sapi/cli/php run-tests.php
>
> =====================================================================
> PHP : sapi/cli/php
> PHP_SAPI : cli
> PHP_VERSION : 7.2.8
> ZEND_VERSION: 3.2.0
> PHP_OS : SunOS - SunOS beta 5.10 Generic_150400-61 sun4u
> INI actual : /usr/local/lib/php.ini
> More .INIs :
> ---------------------------------------------------------------------
> PHP :
> /usr/local/build/php-7.2.8_SunOS5.10_sparc64vii+.001/sapi/phpdbg/phpdbg
> PHP_SAPI : phpdbg
> PHP_VERSION : 7.2.8
> ZEND_VERSION: 3.2.0
> PHP_OS : SunOS - SunOS beta 5.10 Generic_150400-61 sun4u
> INI actual : /usr/local/lib/php.ini
> More .INIs :
> ---------------------------------------------------------------------
> CWD : /usr/local/build/php-7.2.8_SunOS5.10_sparc64vii+.001
> Extra dirs :
> VALGRIND : Not used
> =====================================================================
> TIME START 2018-10-18 19:18:58
> =====================================================================
> Bus Error(coredump)
> beta $
> beta $ dbx sapi/cli/php
> time_1539890338-pid_2068-uid_16411-gid_20002-fid_php.core
> For information about new features see `help changes'
> To remove this message, put `dbxenv suppress_startup_message 8.2' in
> your .dbxrc
> Reading php
> core file header read successfully
> Reading ld.so.1
> Reading libresolv.so.2
> Reading librt.so.1
> Reading libm.so.2
> Reading libnsl.so.1
> Reading libsocket.so.1
> Reading libz.so.1.2.8
> Reading libxml2.so.2.9.2
> Reading liblzma.so.5.2.1
> Reading libpthread.so.1
> Reading libiconv.so.2.6.0
> Reading libc.so.1
> Reading libaio.so.1
> Reading libmd.so.1
> Reading libc_psr.so.1
> Reading en_US.UTF-8.so.3
> Reading methods_unicode.so.3
> t@1 (l@1) program terminated by signal BUS (invalid address alignment)
> Current function is set_label
> 630 label->next = NULL;
> (dbx) where
> current thread: t@1
> =>[1] set_label(label = 0x101ffa82c, compiler = 0x101ff9780), line 630
> in "sljitLir.c"
> [2] sljit_emit_label(compiler = 0x101ff9780), line 1251 in
> "sljitNativeSPARC_common.c"
> [3] php__pcre_jit_compile(re = 0x101ff9570, extra = 0x101ff9600, mode
> = 0), line 11081 in "pcre_jit_compile.c"
> [4] php_pcre_study(external_re = 0x101ff9570, options = 1, errorptr =
> 0xffffffff7fffdb10), line 1630 in "pcre_study.c"
> [5] pcre_get_compiled_regex_cache(regex = 0xffffffff7d0b5630), line
> 548 in "php_pcre.c"
> [6] php_do_pcre_match(execute_data = 0xffffffff7d023810, return_value
> = 0xffffffff7d01efa0, global = 0), line 729 in "php_pcre.c"
> [7] zif_preg_match(execute_data = 0xffffffff7d023810, return_value =
> 0xffffffff7d01efa0), line 1147 in "php_pcre.c"
> [8] ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER(execute_data =
> 0xffffffff7d01e510), line 617 in "zend_vm_execute.h"
> [9] execute_ex(ex = 0xffffffff7d01c030), line 59739 in
> "zend_vm_execute.h"
> [10] zend_execute(op_array = 0xffffffff7d07e540, return_value =
> (nil)), line 63776 in "zend_vm_execute.h"
> [11] zend_execute_scripts(type = 8, retval = (nil), file_count = 3,
> ... = 0x17d06c060, ...), line 1496 in "zend.c"
> [12] php_execute_script(primary_file = 0xffffffff7ffff0f8), line 2590
> in "main.c"
> [13] do_cli(argc = 2, argv = 0x101c8ed20), line 1011 in "php_cli.c"
> [14] main(argc = 2, argv = 0x101c8ed20), line 1404 in "php_cli.c"
> (dbx) list
> 630 label->next = NULL;
> 631 label->size = compiler->size;
> 632 if (compiler->last_label)
> 633 compiler->last_label->next = label;
> 634 else
> 635 compiler->labels = label;
> 636 compiler->last_label = label;
> 637 }
> 638
> 639 static SLJIT_INLINE void set_jump(struct sljit_jump *jump,
> struct sljit_compiler *compiler, sljit_s32 flags)
> (dbx) print label
> label = 0x101ffa82c
> (dbx) print *label
> *label = {
> next = (nil)
> addr = 0
> size = 0
> }
> (dbx) quit
>
> Which has me wonder how that is possible given that I tend to enforce
> a 64-bit alignment with -xmemalign=8s .
>
> Regardless php has been a battle on Solaris sparc. Would love to know
> how you managed to get any sort of reasonable results.
>
>>
>> I did get some false positive fixed by the PHP people, but got
>> somewhat tired of analyzing the big number of failing tests.
>>
>
> I have bug reports filed that seem to rot.
> Others I follow or try to follow :
>
> https://bugs.php.net/bug.php?id=49184
>
> That never seems to go away :
>
> beta $ cat /tmp/foo.php
> <?php
>
> var_dump(
> filter_input(INPUT_SERVER,'ENV_NAME',FILTER_SANITIZE_STRING),
> $_SERVER['ENV_NAME']
> );
>
> ?>
> beta $ sapi/cli/php /tmp/foo.php
> PHP Notice: Undefined index: ENV_NAME in /tmp/foo.php on line 5
> NULL
> NULL
> beta $
>
> beta $ ENV_NAME=foobar sapi/cli/php /tmp/foo.php
> NULL
> string(6) "foobar"
> beta $
>
> beta $ sapi/cli/php --version
> PHP 7.2.8 (cli) (built: Aug 15 2018 03:13:17) ( NTS )
> Copyright (c) 1997-2018 The PHP Group
> Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
> beta $
>
> In any case ... I trust this build of php 7.2.8 about as far as I can
> throw it and I can not throw an M4000 very far at all. Or lift it.
>
> Dennis
httpd and php integration
Posted by Dennis Clarke <dc...@blastwave.org>.
On 10/18/2018 03:42 PM, Rainer Jung wrote:
> Am 18.10.2018 um 21:18 schrieb Dennis Clarke:
>> On 10/18/2018 02:12 PM, Daniel Ruggeri wrote:
>>> php: "5.6.38"
>>
> I do build PHP 7.x myself including recent library versions both on some
> Linux platforms as well as on Solaris Sparc. But the typical use is via
> PHP-FPM, not mod_php. So httpd integration is done via mod_proxy_fcgi
> which is part of httpd nowadays. I do not test PHP with the httpd test
> suite, only with the tests that come with PHP itself.
Yes, I see the php-fpm approach and ye old mod_php was fine for php 5.x
world but the world has moved onwards.
> When running the test suite I typically get about 50-80 test failures on
> Linux and 150-200 test failures on Solaris (of about 13000 non-skipped
> tests).
I get outright SIGBUS core dump :-(
beta $ TEST_PHP_EXECUTABLE=sapi/cli/php sapi/cli/php run-tests.php
=====================================================================
PHP : sapi/cli/php
PHP_SAPI : cli
PHP_VERSION : 7.2.8
ZEND_VERSION: 3.2.0
PHP_OS : SunOS - SunOS beta 5.10 Generic_150400-61 sun4u
INI actual : /usr/local/lib/php.ini
More .INIs :
---------------------------------------------------------------------
PHP :
/usr/local/build/php-7.2.8_SunOS5.10_sparc64vii+.001/sapi/phpdbg/phpdbg
PHP_SAPI : phpdbg
PHP_VERSION : 7.2.8
ZEND_VERSION: 3.2.0
PHP_OS : SunOS - SunOS beta 5.10 Generic_150400-61 sun4u
INI actual : /usr/local/lib/php.ini
More .INIs :
---------------------------------------------------------------------
CWD : /usr/local/build/php-7.2.8_SunOS5.10_sparc64vii+.001
Extra dirs :
VALGRIND : Not used
=====================================================================
TIME START 2018-10-18 19:18:58
=====================================================================
Bus Error(coredump)
beta $
beta $ dbx sapi/cli/php
time_1539890338-pid_2068-uid_16411-gid_20002-fid_php.core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 8.2' in
your .dbxrc
Reading php
core file header read successfully
Reading ld.so.1
Reading libresolv.so.2
Reading librt.so.1
Reading libm.so.2
Reading libnsl.so.1
Reading libsocket.so.1
Reading libz.so.1.2.8
Reading libxml2.so.2.9.2
Reading liblzma.so.5.2.1
Reading libpthread.so.1
Reading libiconv.so.2.6.0
Reading libc.so.1
Reading libaio.so.1
Reading libmd.so.1
Reading libc_psr.so.1
Reading en_US.UTF-8.so.3
Reading methods_unicode.so.3
t@1 (l@1) program terminated by signal BUS (invalid address alignment)
Current function is set_label
630 label->next = NULL;
(dbx) where
current thread: t@1
=>[1] set_label(label = 0x101ffa82c, compiler = 0x101ff9780), line 630
in "sljitLir.c"
[2] sljit_emit_label(compiler = 0x101ff9780), line 1251 in
"sljitNativeSPARC_common.c"
[3] php__pcre_jit_compile(re = 0x101ff9570, extra = 0x101ff9600, mode
= 0), line 11081 in "pcre_jit_compile.c"
[4] php_pcre_study(external_re = 0x101ff9570, options = 1, errorptr =
0xffffffff7fffdb10), line 1630 in "pcre_study.c"
[5] pcre_get_compiled_regex_cache(regex = 0xffffffff7d0b5630), line
548 in "php_pcre.c"
[6] php_do_pcre_match(execute_data = 0xffffffff7d023810, return_value
= 0xffffffff7d01efa0, global = 0), line 729 in "php_pcre.c"
[7] zif_preg_match(execute_data = 0xffffffff7d023810, return_value =
0xffffffff7d01efa0), line 1147 in "php_pcre.c"
[8] ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER(execute_data =
0xffffffff7d01e510), line 617 in "zend_vm_execute.h"
[9] execute_ex(ex = 0xffffffff7d01c030), line 59739 in
"zend_vm_execute.h"
[10] zend_execute(op_array = 0xffffffff7d07e540, return_value =
(nil)), line 63776 in "zend_vm_execute.h"
[11] zend_execute_scripts(type = 8, retval = (nil), file_count = 3,
... = 0x17d06c060, ...), line 1496 in "zend.c"
[12] php_execute_script(primary_file = 0xffffffff7ffff0f8), line 2590
in "main.c"
[13] do_cli(argc = 2, argv = 0x101c8ed20), line 1011 in "php_cli.c"
[14] main(argc = 2, argv = 0x101c8ed20), line 1404 in "php_cli.c"
(dbx) list
630 label->next = NULL;
631 label->size = compiler->size;
632 if (compiler->last_label)
633 compiler->last_label->next = label;
634 else
635 compiler->labels = label;
636 compiler->last_label = label;
637 }
638
639 static SLJIT_INLINE void set_jump(struct sljit_jump *jump,
struct sljit_compiler *compiler, sljit_s32 flags)
(dbx) print label
label = 0x101ffa82c
(dbx) print *label
*label = {
next = (nil)
addr = 0
size = 0
}
(dbx) quit
Which has me wonder how that is possible given that I tend to enforce
a 64-bit alignment with -xmemalign=8s .
Regardless php has been a battle on Solaris sparc. Would love to know
how you managed to get any sort of reasonable results.
>
> I did get some false positive fixed by the PHP people, but got somewhat
> tired of analyzing the big number of failing tests.
>
I have bug reports filed that seem to rot.
Others I follow or try to follow :
https://bugs.php.net/bug.php?id=49184
That never seems to go away :
beta $ cat /tmp/foo.php
<?php
var_dump(
filter_input(INPUT_SERVER,'ENV_NAME',FILTER_SANITIZE_STRING),
$_SERVER['ENV_NAME']
);
?>
beta $ sapi/cli/php /tmp/foo.php
PHP Notice: Undefined index: ENV_NAME in /tmp/foo.php on line 5
NULL
NULL
beta $
beta $ ENV_NAME=foobar sapi/cli/php /tmp/foo.php
NULL
string(6) "foobar"
beta $
beta $ sapi/cli/php --version
PHP 7.2.8 (cli) (built: Aug 15 2018 03:13:17) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
beta $
In any case ... I trust this build of php 7.2.8 about as far as I can
throw it and I can not throw an M4000 very far at all. Or lift it.
Dennis
Re: [VOTE] Release httpd-2.4.37
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.10.2018 um 21:18 schrieb Dennis Clarke:
> On 10/18/2018 02:12 PM, Daniel Ruggeri wrote:
>> php: "5.6.38"
>
> Slightly off topic but I see you have ye old php 5.6.38 there. Was this
> built and installed yourself?
>
> Just curious is there is any guidance anywhere regarding php 7.x which
> builds but it is a religious experience complete with prayer and black
> cats under a full moon and scotch :
>
> beta $ ./sapi/cli/php --version
> PHP 7.2.8 (cli) (built: Aug 15 2018 03:13:17) ( NTS )
> Copyright (c) 1997-2018 The PHP Group
> Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
> beta $
>
> beta $ file ./sapi/cli/php
> ./sapi/cli/php: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
> linked, not stripped
> beta $
>
> The php folks are entirely and completely horrific at dealing with
> anything that appears broken and their testing docs are quite blunt
> about the fact that they don't want to hear from you. In fact, you
> are wrong, they are correct, go away :
>
> beta $ more README.TESTING
> [IMPORTANT NOTICE]
> ------------------
> Failed tests usually indicate a problem with your local system setup
> and not within PHP itself (at least for official PHP release versions).
> You may decide to automatically submit a test summary to our QA workflow
> at the end of a test run.
> Please do *not* submit a failed test as a bug or ask for help on why
> it failed on your system without providing substantial backup information
> on *why* the test failed on your special setup. Thank you :-)
>
>
> So have you tried anything with php 7.x from sources and made any
> progress with manually integrating httpd and php 7.x ??
>
> Dennis Clarke
I do build PHP 7.x myself including recent library versions both on some
Linux platforms as well as on Solaris Sparc. But the typical use is via
PHP-FPM, not mod_php. So httpd integration is done via mod_proxy_fcgi
which is part of httpd nowadays. I do not test PHP with the httpd test
suite, only with the tests that come with PHP itself.
When running the test suite I typically get about 50-80 test failures on
Linux and 150-200 test failures on Solaris (of about 13000 non-skipped
tests).
I did get some false positive fixed by the PHP people, but got somewhat
tired of analyzing the big number of failing tests.
Regards,
Rainer
Re: [VOTE] Release httpd-2.4.37
Posted by Dennis Clarke <dc...@blastwave.org>.
On 10/18/2018 02:12 PM, Daniel Ruggeri wrote:
> php: "5.6.38"
Slightly off topic but I see you have ye old php 5.6.38 there. Was this
built and installed yourself?
Just curious is there is any guidance anywhere regarding php 7.x which
builds but it is a religious experience complete with prayer and black
cats under a full moon and scotch :
beta $ ./sapi/cli/php --version
PHP 7.2.8 (cli) (built: Aug 15 2018 03:13:17) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
beta $
beta $ file ./sapi/cli/php
./sapi/cli/php: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
linked, not stripped
beta $
The php folks are entirely and completely horrific at dealing with
anything that appears broken and their testing docs are quite blunt
about the fact that they don't want to hear from you. In fact, you
are wrong, they are correct, go away :
beta $ more README.TESTING
[IMPORTANT NOTICE]
------------------
Failed tests usually indicate a problem with your local system setup
and not within PHP itself (at least for official PHP release versions).
You may decide to automatically submit a test summary to our QA workflow
at the end of a test run.
Please do *not* submit a failed test as a bug or ask for help on why
it failed on your system without providing substantial backup information
on *why* the test failed on your special setup. Thank you :-)
So have you tried anything with php 7.x from sources and made any
progress with manually integrating httpd and php 7.x ??
Dennis Clarke
Re: [VOTE] Release httpd-2.4.37
Posted by Daniel Ruggeri <dr...@primary.net>.
On 2018-10-18 09:36, Daniel Ruggeri wrote:
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.37:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
> sha256:
> aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
> *httpd-2.4.37.tar.gz
+1 from me based on the following setup
system:
kernel:
name: Linux
release: 3.16.0-4-amd64
version: #1 SMP Debian 3.16.51-3 (2017-12-13)
machine: x86_64
libraries:
openssl: "1.1.1"
openldap: "2.4.46"
apr: "1.6.5"
apr-util: "1.6.1"
iconv: "1.2.2"
brotli: "1.0.6"
nghttp2: "1.34.0"
zlib: "1.2.11"
pcre: "8.42"
libxml2: "2.9.8"
php: "5.6.38"
lua: "5.3.5"
curl: "7.61.1"
--
Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.37
Posted by de...@gmail.com,
de...@gmail.com.
+1
FreeBSD 11.2-RELEASE-p4 amd64
openssl111-1.1.1_1
perl5-5.28.0
php72-7.2.11
Tested both prefork and event MPM
--
Dennis
Re: [VOTE] Release httpd-2.4.37
Posted by Daniel Ruggeri <dr...@primary.net>.
Hi, Cory;
Yes, you are correct. This gets cleaned up as part of the final
fixups in the release scripts. It's one of the things done at the last
moment :-)
--
Daniel Ruggeri
On 2018-10-22 10:23, Cory McIntire wrote:
> Just a note, the date here is Sept instead of Oct :)
>
> http://httpd.apache.org/dev/dist/Announcement2.4.html
> http://httpd.apache.org/dev/dist/Announcement2.4.txt
>
> (I realize this might not be final version of said text.. just wanted
> to mention)
>
> Thanks
> Cory McIntire
> Release Manager - EasyApache
> cPanel, L.L.C.
>
>
>> On Oct 22, 2018, at 9:08 AM, Daniel Ruggeri <dr...@primary.net>
>> wrote:
>>
>> On 2018-10-18 09:36, Daniel Ruggeri wrote:
>>> Hi, all;
>>> Please find below the proposed release tarball and signatures:
>>> https://dist.apache.org/repos/dist/dev/httpd/
>>> I would like to call a VOTE over the next few days to release this
>>> candidate tarball as 2.4.37:
>>> [ ] +1: It's not just good, it's good enough!
>>> [ ] +0: Let's have a talk.
>>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>> The computed digests of the tarball up for vote are:
>>> sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
>>> sha256:
>>> aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
>>> *httpd-2.4.37.tar.gz
>>
>> Hello, all;
>> I am pleased to announce that the release vote has PASSED with the
>> following recorded votes.
>>
>> PMC
>> druggeri, jorton, jim, icing, jailletc36, ylavic, rjung
>>
>> Community
>> Dennis Radford
>>
>> I will begin the process of syncing the mirrors and preparing the
>> final Announce text.
>>
>> I'd like to give a big thank you for all the folks who put effort into
>> creating the code for this release and the effort spent testing this
>> release!
>>
>> --
>> Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.37
Posted by Cory McIntire <co...@cpanel.net>.
Just a note, the date here is Sept instead of Oct :)
http://httpd.apache.org/dev/dist/Announcement2.4.html
http://httpd.apache.org/dev/dist/Announcement2.4.txt
(I realize this might not be final version of said text.. just wanted to mention)
Thanks
Cory McIntire
Release Manager - EasyApache
cPanel, L.L.C.
> On Oct 22, 2018, at 9:08 AM, Daniel Ruggeri <dr...@primary.net> wrote:
>
> On 2018-10-18 09:36, Daniel Ruggeri wrote:
>> Hi, all;
>> Please find below the proposed release tarball and signatures:
>> https://dist.apache.org/repos/dist/dev/httpd/
>> I would like to call a VOTE over the next few days to release this
>> candidate tarball as 2.4.37:
>> [ ] +1: It's not just good, it's good enough!
>> [ ] +0: Let's have a talk.
>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>> The computed digests of the tarball up for vote are:
>> sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
>> sha256:
>> aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
>> *httpd-2.4.37.tar.gz
>
> Hello, all;
> I am pleased to announce that the release vote has PASSED with the following recorded votes.
>
> PMC
> druggeri, jorton, jim, icing, jailletc36, ylavic, rjung
>
> Community
> Dennis Radford
>
> I will begin the process of syncing the mirrors and preparing the final Announce text.
>
> I'd like to give a big thank you for all the folks who put effort into creating the code for this release and the effort spent testing this release!
>
> --
> Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.37
Posted by Daniel Ruggeri <dr...@primary.net>.
On 2018-10-23 14:04, Ruediger Pluem wrote:
> On 10/22/2018 04:08 PM, Daniel Ruggeri wrote:
>> On 2018-10-18 09:36, Daniel Ruggeri wrote:
>>> Hi, all;
>>> Please find below the proposed release tarball and signatures:
>>> https://dist.apache.org/repos/dist/dev/httpd/
>>>
>>> I would like to call a VOTE over the next few days to release this
>>> candidate tarball as 2.4.37:
>>> [ ] +1: It's not just good, it's good enough!
>>> [ ] +0: Let's have a talk.
>>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>>
>>> The computed digests of the tarball up for vote are:
>>> sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
>>> sha256:
>>> aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
>>> *httpd-2.4.37.tar.gz
>>
>> Hello, all;
>> I am pleased to announce that the release vote has PASSED with the
>> following recorded votes.
>>
>> PMC
>> druggeri, jorton, jim, icing, jailletc36, ylavic, rjung
>>
>> Community
>> Dennis Radford
>>
>> I will begin the process of syncing the mirrors and preparing the
>> final Announce text.
>>
>> I'd like to give a big thank you for all the folks who put effort into
>> creating the code for this release and the effort
>> spent testing this release!
>
> Just as a side-note that may be a bug in your scripts:
>
> http://www.apache.org/dist/httpd/CHANGES_2.4 still stops at 2.4.35
> while
> http://www.apache.org/dist/httpd/CHANGES_2.4.37 is correct.
> Thanks for the great scripts and RMing.
>
> Regards
>
> Rüdiger
Yikes! Thanks - no idea how that slipped through. I just fixed it
manually and will triage/update the script.
--
Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.37
Posted by Ruediger Pluem <rp...@apache.org>.
On 10/22/2018 04:08 PM, Daniel Ruggeri wrote:
> On 2018-10-18 09:36, Daniel Ruggeri wrote:
>> Hi, all;
>> Please find below the proposed release tarball and signatures:
>> https://dist.apache.org/repos/dist/dev/httpd/
>>
>> I would like to call a VOTE over the next few days to release this
>> candidate tarball as 2.4.37:
>> [ ] +1: It's not just good, it's good enough!
>> [ ] +0: Let's have a talk.
>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>
>> The computed digests of the tarball up for vote are:
>> sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
>> sha256:
>> aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
>> *httpd-2.4.37.tar.gz
>
> Hello, all;
> I am pleased to announce that the release vote has PASSED with the following recorded votes.
>
> PMC
> druggeri, jorton, jim, icing, jailletc36, ylavic, rjung
>
> Community
> Dennis Radford
>
> I will begin the process of syncing the mirrors and preparing the final Announce text.
>
> I'd like to give a big thank you for all the folks who put effort into creating the code for this release and the effort
> spent testing this release!
Just as a side-note that may be a bug in your scripts:
http://www.apache.org/dist/httpd/CHANGES_2.4 still stops at 2.4.35 while
http://www.apache.org/dist/httpd/CHANGES_2.4.37 is correct.
Thanks for the great scripts and RMing.
Regards
Rüdiger
Re: [VOTE] Release httpd-2.4.37
Posted by Daniel Ruggeri <dr...@primary.net>.
On 2018-10-18 09:36, Daniel Ruggeri wrote:
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.37:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
> sha256:
> aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
> *httpd-2.4.37.tar.gz
Hello, all;
I am pleased to announce that the release vote has PASSED with the
following recorded votes.
PMC
druggeri, jorton, jim, icing, jailletc36, ylavic, rjung
Community
Dennis Radford
I will begin the process of syncing the mirrors and preparing the final
Announce text.
I'd like to give a big thank you for all the folks who put effort into
creating the code for this release and the effort spent testing this
release!
--
Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.37
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Oct 18, 2018 at 09:36:41AM -0500, Daniel Ruggeri wrote:
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this candidate
> tarball as 2.4.37:
> [X] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
+1 for release from me, thanks again for RMing again ;)
Regards, Joe
Re: Test suite and OpenSSL 1.1.1
Posted by Rainer Jung <ra...@kippdata.de>.
Am 20.10.2018 um 13:26 schrieb Christophe JAILLET:
> Le 20/10/2018 à 11:00, Rainer Jung a écrit :
>> Am 20.10.2018 um 10:27 schrieb Christophe JAILLET:
>>> Le 20/10/2018 à 09:56, Rainer Jung a écrit :
>>>> Am 20.10.2018 um 09:39 schrieb Christophe JAILLET:
>>>>> Le 20/10/2018 à 06:28, Rainer Jung a écrit :
>>>>>> Am 19.10.2018 um 23:31 schrieb Yann Ylavic:
>>>>>>> Could not make the test suite framework work with 1.1.1 (cpan -u
>>>>>>> didn't help).
>>>>>>> Although the ssl tests report SUCCESS, httpd actually timeouts on
>>>>>>> SSL_peek() (as already reported).
>>>>>>
>>>>>> Indeed I checked my test suite logs and until now all tests only
>>>>>> used TLS 1.2. But what works for me now with TLS 1.3 is:
>>>>>>
>>>>>> - small fix in TestSSLCA.pm (r1844389), otherwise the geneated
>>>>>> t/conf/ssl/ssl.conf always contains "SSLProtocol all -TLSv1.3"
>>>>>> instead of "all" (unless you specifiy -sslproto explicitly).
>>>>>>
>>>>>>
>>>>> I've just updated the test framework.
>>>>> make clean
>>>>> t/TEST
>>>>> --> ssl.conf rebuilt
>>>>>
>>>>> But I still have:
>>>>> SSLProtocol all -TLSv1.3
>>>>
>>>> I didn't manage to rebuild ssl.conf using make, but what I did to
>>>> rebuild was a "t/TEST -v -configure" and to make sure I removed the
>>>> ssl.conf file before running that command. This resulted in a new
>>>> file with "all" in it.
>>>>
>>>> Please also double check, that TestSSLCA.pm contains the line "use
>>>> Net::SSLeay;".
>>>>
>>>> Does it work with that recipe?
>>>>
>>>> Thanks and regards,
>>
>>> use Net::SSLeay;
>>> is there.
>>>
>>>
>>> Comment added in ssl.conf.in gets reflected in ssl.conf, so it is
>>> rebuilt.
>>>
>>>
>>> t/TEST -v -configure
>>> [warning] setting ulimit to allow core files
>>> ulimit -c unlimited; /usr/bin/perl
>>> /home/tititou36/svn_test_framework/t/TEST -v -configure
>>> [warning] cleaning out current configuration
>>> [warning] skipping rebuild of c-modules; run t/TEST -clean to force
>>> [warning] skipping regeneration of SSL CA; run t/TEST -clean to force
>>> make: rien à faire pour « all ».
>>> [warning] reconfiguration done
>>>
>>> But SSLProtocol all -TLSv1.3 is still there.
>>>
>>>
>>> t/TEST -clean
>>> doesn't help either.
>>
>> The check, wheher "all" or "all -TLSv1.3" is put into the file is done
>> in TestSSLCA.pm. The code there checks the following, which you can
>> also check in a test script to see, which condition fails:
>>
>> Apache::Test::normalize_vstring(Apache::Test::version()) >=
>> Apache::Test::normalize_vstring("1.1.1")
>>
>> and
>>
>> defined(&Net::SSLeay::CTX_set_post_handshake_auth)
>>
>> The first looks for the OpenSSL version caused by your test framework,
>> the second checks, whether Net::SSLeay is current (actually at least
>> developer snapshot 1.86_06). Both is needed to make TLS 1.3 work in
>> the test framework.
>>
>> To check standalone you can use a script like this:
>>
>> === SNIP ===
>>
>> #!/usr/bin/perl
>>
>> use strict;
>> use Net::SSLeay;
>> use IO::Socket::SSL;
>> use Apache::Test;
>> use Apache::TestSSLCA;
>>
>> my $version = Apache::TestSSLCA::version();
>> print "OpenSSL version: $version\n";
>> print "Normalized OpenSSL version: " .
>> Apache::Test::normalize_vstring($version) . "\n";
>> print "Normalized 1.1.1 version: " .
>> Apache::Test::normalize_vstring("1.1.1") . "\n";
>> print "Net::SSLeay::VERSION: $Net::SSLeay::VERSION\n";
>> print "IO::Socket::SSL::VERSION: $IO::Socket::SSL::VERSION\n";
>> print "Net::SSLeay::CTX_set_post_handshake_auth available: " .
>> (defined(&Net::SSLeay::CTX_set_post_handshake_auth) ?
>> "true" : "false") . "\n";
>> my $tls13 = (Apache::Test::normalize_vstring($version) >=
>> Apache::Test::normalize_vstring("1.1.1")) &&
>> defined(&Net::SSLeay::CTX_set_post_handshake_auth);
>> print "TLSv1.3 support: " . ($tls13 ? "true" : "false") . "\n";
>>
>> === SNIP ===
>>
>> To run it you must also provide the path to the test framework and if
>> you have installed the additional moduls needed by the framework in
>> some special place, you must also provide this one, both via "-I" flag:
>>
>> perl -I /path/to/bundle/lib/perl5 -I /path/to/Apache-Test/lib test.pl
>>
>> When I run this I get:
>>
>> OpenSSL version: 1.1.1
>> Normalized OpenSSL version: 001001001
>> Normalized 1.1.1 version: 001001001
>> Net::SSLeay::VERSION: 1.86_06
>> IO::Socket::SSL::VERSION: 2.060
>> Net::SSLeay::CTX_set_post_handshake_auth available: true
>> TLSv1.3 support: true
>>
>> Most likely your version of Net::SSLeay is to old.
>>
>> In adition, once the framework detects TLSv1.3 correct, you also need
>> IO::Socket::SSL 2.060 plus the one patch for its SSL.pm that I
>> mentioned at the beginning of this thread.
>>
>> Regards,
>>
>> Rainer
>>
> OpenSSL version: 1.1.1
> Normalized OpenSSL version: 001001001
> Normalized 1.1.1 version: 001001001
> Net::SSLeay::VERSION: 1.85 <-------------
> IO::Socket::SSL::VERSION: 2.060
> Net::SSLeay::CTX_set_post_handshake_auth available: false
> TLSv1.3 support: false <-------------
>
> When I try to update it using perl -MCPAN -e ..., I get:
>
> Net::SSLeay is up to date (1.85).
> which is in line with https://metacpan.org/pod/Net::SSLeay
>
>
> I will have to wait for cpan to have a more recent version, when
> released, I guess.
>
> Thanks for the explanations.
That will be easiest. I downloaded the source tarball from github,
extacted and then ran from the new directory:
perl Makefile.PL
make
make test
make install
But it might get slightly more complex if you want the install to go
into some special directory tree instead of into the system perl
installation.
Regards,
Rainer
Re: Test suite and OpenSSL 1.1.1
Posted by Christophe JAILLET <ch...@wanadoo.fr>.
Le 20/10/2018 à 11:00, Rainer Jung a écrit :
> Am 20.10.2018 um 10:27 schrieb Christophe JAILLET:
>> Le 20/10/2018 à 09:56, Rainer Jung a écrit :
>>> Am 20.10.2018 um 09:39 schrieb Christophe JAILLET:
>>>> Le 20/10/2018 à 06:28, Rainer Jung a écrit :
>>>>> Am 19.10.2018 um 23:31 schrieb Yann Ylavic:
>>>>>> Could not make the test suite framework work with 1.1.1 (cpan -u
>>>>>> didn't help).
>>>>>> Although the ssl tests report SUCCESS, httpd actually timeouts on
>>>>>> SSL_peek() (as already reported).
>>>>>
>>>>> Indeed I checked my test suite logs and until now all tests only
>>>>> used TLS 1.2. But what works for me now with TLS 1.3 is:
>>>>>
>>>>> - small fix in TestSSLCA.pm (r1844389), otherwise the geneated
>>>>> t/conf/ssl/ssl.conf always contains "SSLProtocol all -TLSv1.3"
>>>>> instead of "all" (unless you specifiy -sslproto explicitly).
>>>>>
>>>>>
>>>> I've just updated the test framework.
>>>> make clean
>>>> t/TEST
>>>> --> ssl.conf rebuilt
>>>>
>>>> But I still have:
>>>> SSLProtocol all -TLSv1.3
>>>
>>> I didn't manage to rebuild ssl.conf using make, but what I did to
>>> rebuild was a "t/TEST -v -configure" and to make sure I removed the
>>> ssl.conf file before running that command. This resulted in a new
>>> file with "all" in it.
>>>
>>> Please also double check, that TestSSLCA.pm contains the line "use
>>> Net::SSLeay;".
>>>
>>> Does it work with that recipe?
>>>
>>> Thanks and regards,
>
>> use Net::SSLeay;
>> is there.
>>
>>
>> Comment added in ssl.conf.in gets reflected in ssl.conf, so it is
>> rebuilt.
>>
>>
>> t/TEST -v -configure
>> [warning] setting ulimit to allow core files
>> ulimit -c unlimited; /usr/bin/perl
>> /home/tititou36/svn_test_framework/t/TEST -v -configure
>> [warning] cleaning out current configuration
>> [warning] skipping rebuild of c-modules; run t/TEST -clean to force
>> [warning] skipping regeneration of SSL CA; run t/TEST -clean to force
>> make: rien à faire pour « all ».
>> [warning] reconfiguration done
>>
>> But SSLProtocol all -TLSv1.3 is still there.
>>
>>
>> t/TEST -clean
>> doesn't help either.
>
> The check, wheher "all" or "all -TLSv1.3" is put into the file is done
> in TestSSLCA.pm. The code there checks the following, which you can
> also check in a test script to see, which condition fails:
>
> Apache::Test::normalize_vstring(Apache::Test::version()) >=
> Apache::Test::normalize_vstring("1.1.1")
>
> and
>
> defined(&Net::SSLeay::CTX_set_post_handshake_auth)
>
> The first looks for the OpenSSL version caused by your test framework,
> the second checks, whether Net::SSLeay is current (actually at least
> developer snapshot 1.86_06). Both is needed to make TLS 1.3 work in
> the test framework.
>
> To check standalone you can use a script like this:
>
> === SNIP ===
>
> #!/usr/bin/perl
>
> use strict;
> use Net::SSLeay;
> use IO::Socket::SSL;
> use Apache::Test;
> use Apache::TestSSLCA;
>
> my $version = Apache::TestSSLCA::version();
> print "OpenSSL version: $version\n";
> print "Normalized OpenSSL version: " .
> Apache::Test::normalize_vstring($version) . "\n";
> print "Normalized 1.1.1 version: " .
> Apache::Test::normalize_vstring("1.1.1") . "\n";
> print "Net::SSLeay::VERSION: $Net::SSLeay::VERSION\n";
> print "IO::Socket::SSL::VERSION: $IO::Socket::SSL::VERSION\n";
> print "Net::SSLeay::CTX_set_post_handshake_auth available: " .
> (defined(&Net::SSLeay::CTX_set_post_handshake_auth) ?
> "true" : "false") . "\n";
> my $tls13 = (Apache::Test::normalize_vstring($version) >=
> Apache::Test::normalize_vstring("1.1.1")) &&
> defined(&Net::SSLeay::CTX_set_post_handshake_auth);
> print "TLSv1.3 support: " . ($tls13 ? "true" : "false") . "\n";
>
> === SNIP ===
>
> To run it you must also provide the path to the test framework and if
> you have installed the additional moduls needed by the framework in
> some special place, you must also provide this one, both via "-I" flag:
>
> perl -I /path/to/bundle/lib/perl5 -I /path/to/Apache-Test/lib test.pl
>
> When I run this I get:
>
> OpenSSL version: 1.1.1
> Normalized OpenSSL version: 001001001
> Normalized 1.1.1 version: 001001001
> Net::SSLeay::VERSION: 1.86_06
> IO::Socket::SSL::VERSION: 2.060
> Net::SSLeay::CTX_set_post_handshake_auth available: true
> TLSv1.3 support: true
>
> Most likely your version of Net::SSLeay is to old.
>
> In adition, once the framework detects TLSv1.3 correct, you also need
> IO::Socket::SSL 2.060 plus the one patch for its SSL.pm that I
> mentioned at the beginning of this thread.
>
> Regards,
>
> Rainer
>
OpenSSL version: 1.1.1
Normalized OpenSSL version: 001001001
Normalized 1.1.1 version: 001001001
Net::SSLeay::VERSION: 1.85 <-------------
IO::Socket::SSL::VERSION: 2.060
Net::SSLeay::CTX_set_post_handshake_auth available: false
TLSv1.3 support: false <-------------
When I try to update it using perl -MCPAN -e ..., I get:
Net::SSLeay is up to date (1.85).
which is in line with https://metacpan.org/pod/Net::SSLeay
I will have to wait for cpan to have a more recent version, when
released, I guess.
Thanks for the explanations.
CJ
Re: Test suite and OpenSSL 1.1.1
Posted by Rainer Jung <ra...@kippdata.de>.
Am 20.10.2018 um 10:27 schrieb Christophe JAILLET:
> Le 20/10/2018 à 09:56, Rainer Jung a écrit :
>> Am 20.10.2018 um 09:39 schrieb Christophe JAILLET:
>>> Le 20/10/2018 à 06:28, Rainer Jung a écrit :
>>>> Am 19.10.2018 um 23:31 schrieb Yann Ylavic:
>>>>> Could not make the test suite framework work with 1.1.1 (cpan -u
>>>>> didn't help).
>>>>> Although the ssl tests report SUCCESS, httpd actually timeouts on
>>>>> SSL_peek() (as already reported).
>>>>
>>>> Indeed I checked my test suite logs and until now all tests only
>>>> used TLS 1.2. But what works for me now with TLS 1.3 is:
>>>>
>>>> - small fix in TestSSLCA.pm (r1844389), otherwise the geneated
>>>> t/conf/ssl/ssl.conf always contains "SSLProtocol all -TLSv1.3"
>>>> instead of "all" (unless you specifiy -sslproto explicitly).
>>>>
>>>>
>>> I've just updated the test framework.
>>> make clean
>>> t/TEST
>>> --> ssl.conf rebuilt
>>>
>>> But I still have:
>>> SSLProtocol all -TLSv1.3
>>
>> I didn't manage to rebuild ssl.conf using make, but what I did to
>> rebuild was a "t/TEST -v -configure" and to make sure I removed the
>> ssl.conf file before running that command. This resulted in a new file
>> with "all" in it.
>>
>> Please also double check, that TestSSLCA.pm contains the line "use
>> Net::SSLeay;".
>>
>> Does it work with that recipe?
>>
>> Thanks and regards,
> use Net::SSLeay;
> is there.
>
>
> Comment added in ssl.conf.in gets reflected in ssl.conf, so it is rebuilt.
>
>
> t/TEST -v -configure
> [warning] setting ulimit to allow core files
> ulimit -c unlimited; /usr/bin/perl
> /home/tititou36/svn_test_framework/t/TEST -v -configure
> [warning] cleaning out current configuration
> [warning] skipping rebuild of c-modules; run t/TEST -clean to force
> [warning] skipping regeneration of SSL CA; run t/TEST -clean to force
> make: rien à faire pour « all ».
> [warning] reconfiguration done
>
> But SSLProtocol all -TLSv1.3 is still there.
>
>
> t/TEST -clean
> doesn't help either.
The check, wheher "all" or "all -TLSv1.3" is put into the file is done
in TestSSLCA.pm. The code there checks the following, which you can also
check in a test script to see, which condition fails:
Apache::Test::normalize_vstring(Apache::Test::version()) >=
Apache::Test::normalize_vstring("1.1.1")
and
defined(&Net::SSLeay::CTX_set_post_handshake_auth)
The first looks for the OpenSSL version caused by your test framework,
the second checks, whether Net::SSLeay is current (actually at least
developer snapshot 1.86_06). Both is needed to make TLS 1.3 work in the
test framework.
To check standalone you can use a script like this:
=== SNIP ===
#!/usr/bin/perl
use strict;
use Net::SSLeay;
use IO::Socket::SSL;
use Apache::Test;
use Apache::TestSSLCA;
my $version = Apache::TestSSLCA::version();
print "OpenSSL version: $version\n";
print "Normalized OpenSSL version: " .
Apache::Test::normalize_vstring($version) . "\n";
print "Normalized 1.1.1 version: " .
Apache::Test::normalize_vstring("1.1.1") . "\n";
print "Net::SSLeay::VERSION: $Net::SSLeay::VERSION\n";
print "IO::Socket::SSL::VERSION: $IO::Socket::SSL::VERSION\n";
print "Net::SSLeay::CTX_set_post_handshake_auth available: " .
(defined(&Net::SSLeay::CTX_set_post_handshake_auth) ?
"true" : "false") . "\n";
my $tls13 = (Apache::Test::normalize_vstring($version) >=
Apache::Test::normalize_vstring("1.1.1")) &&
defined(&Net::SSLeay::CTX_set_post_handshake_auth);
print "TLSv1.3 support: " . ($tls13 ? "true" : "false") . "\n";
=== SNIP ===
To run it you must also provide the path to the test framework and if
you have installed the additional moduls needed by the framework in some
special place, you must also provide this one, both via "-I" flag:
perl -I /path/to/bundle/lib/perl5 -I /path/to/Apache-Test/lib test.pl
When I run this I get:
OpenSSL version: 1.1.1
Normalized OpenSSL version: 001001001
Normalized 1.1.1 version: 001001001
Net::SSLeay::VERSION: 1.86_06
IO::Socket::SSL::VERSION: 2.060
Net::SSLeay::CTX_set_post_handshake_auth available: true
TLSv1.3 support: true
Most likely your version of Net::SSLeay is to old.
In adition, once the framework detects TLSv1.3 correct, you also need
IO::Socket::SSL 2.060 plus the one patch for its SSL.pm that I mentioned
at the beginning of this thread.
Regards,
Rainer
Re: Test suite and OpenSSL 1.1.1
Posted by Christophe JAILLET <ch...@wanadoo.fr>.
Le 20/10/2018 à 09:56, Rainer Jung a écrit :
> Hi,
>
> Am 20.10.2018 um 09:39 schrieb Christophe JAILLET:
>> Le 20/10/2018 à 06:28, Rainer Jung a écrit :
>>> Am 19.10.2018 um 23:31 schrieb Yann Ylavic:
>>>> Could not make the test suite framework work with 1.1.1 (cpan -u
>>>> didn't help).
>>>> Although the ssl tests report SUCCESS, httpd actually timeouts on
>>>> SSL_peek() (as already reported).
>>>
>>> Indeed I checked my test suite logs and until now all tests only
>>> used TLS 1.2. But what works for me now with TLS 1.3 is:
>>>
>>> - small fix in TestSSLCA.pm (r1844389), otherwise the geneated
>>> t/conf/ssl/ssl.conf always contains "SSLProtocol all -TLSv1.3"
>>> instead of "all" (unless you specifiy -sslproto explicitly).
>>>
>>>
>> I've just updated the test framework.
>> make clean
>> t/TEST
>> --> ssl.conf rebuilt
>>
>> But I still have:
>> SSLProtocol all -TLSv1.3
>
> I didn't manage to rebuild ssl.conf using make, but what I did to
> rebuild was a "t/TEST -v -configure" and to make sure I removed the
> ssl.conf file before running that command. This resulted in a new file
> with "all" in it.
>
> Please also double check, that TestSSLCA.pm contains the line "use
> Net::SSLeay;".
>
> Does it work with that recipe?
>
> Thanks and regards,
>
> Rainer
>
>
use Net::SSLeay;
is there.
Comment added in ssl.conf.in gets reflected in ssl.conf, so it is rebuilt.
t/TEST -v -configure
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl
/home/tititou36/svn_test_framework/t/TEST -v -configure
[warning] cleaning out current configuration
[warning] skipping rebuild of c-modules; run t/TEST -clean to force
[warning] skipping regeneration of SSL CA; run t/TEST -clean to force
make: rien à faire pour « all ».
[warning] reconfiguration done
But SSLProtocol all -TLSv1.3 is still there.
t/TEST -clean
doesn't help either.
CJ
Re: Test suite and OpenSSL 1.1.1
Posted by Rainer Jung <ra...@kippdata.de>.
Hi,
Am 20.10.2018 um 09:39 schrieb Christophe JAILLET:
> Le 20/10/2018 à 06:28, Rainer Jung a écrit :
>> Am 19.10.2018 um 23:31 schrieb Yann Ylavic:
>>> Could not make the test suite framework work with 1.1.1 (cpan -u
>>> didn't help).
>>> Although the ssl tests report SUCCESS, httpd actually timeouts on
>>> SSL_peek() (as already reported).
>>
>> Indeed I checked my test suite logs and until now all tests only used
>> TLS 1.2. But what works for me now with TLS 1.3 is:
>>
>> - small fix in TestSSLCA.pm (r1844389), otherwise the geneated
>> t/conf/ssl/ssl.conf always contains "SSLProtocol all -TLSv1.3" instead
>> of "all" (unless you specifiy -sslproto explicitly).
>>
>>
> I've just updated the test framework.
> make clean
> t/TEST
> --> ssl.conf rebuilt
>
> But I still have:
> SSLProtocol all -TLSv1.3
I didn't manage to rebuild ssl.conf using make, but what I did to
rebuild was a "t/TEST -v -configure" and to make sure I removed the
ssl.conf file before running that command. This resulted in a new file
with "all" in it.
Please also double check, that TestSSLCA.pm contains the line "use
Net::SSLeay;".
Does it work with that recipe?
Thanks and regards,
Rainer
Re: Test suite and OpenSSL 1.1.1
Posted by Christophe JAILLET <ch...@wanadoo.fr>.
Le 20/10/2018 à 06:28, Rainer Jung a écrit :
> Am 19.10.2018 um 23:31 schrieb Yann Ylavic:
>> Could not make the test suite framework work with 1.1.1 (cpan -u
>> didn't help).
>> Although the ssl tests report SUCCESS, httpd actually timeouts on
>> SSL_peek() (as already reported).
>
> Indeed I checked my test suite logs and until now all tests only used
> TLS 1.2. But what works for me now with TLS 1.3 is:
>
> - small fix in TestSSLCA.pm (r1844389), otherwise the geneated
> t/conf/ssl/ssl.conf always contains "SSLProtocol all -TLSv1.3" instead
> of "all" (unless you specifiy -sslproto explicitly).
>
>
I've just updated the test framework.
make clean
t/TEST
--> ssl.conf rebuilt
But I still have:
SSLProtocol all -TLSv1.3
CJ
Re: Test suite and OpenSSL 1.1.1
Posted by Rainer Jung <ra...@kippdata.de>.
Plus r1844425 which simplifies TestRequest.pm since IO::Socket::SSL has
a working getline().
Am 20.10.2018 um 09:59 schrieb Rainer Jung:
> I now also added r1844396 to allow setting the CA for peer cert
> verification and used it in echo.t and nttp-like.t to unbreak their ssl
> testing (r1844397).
>
> I didn't find more uses of the raw sockets.
>
> Regards,
>
> Rainer
>
> Am 20.10.2018 um 08:47 schrieb Rainer Jung:
>> To make the raw TLS socket tests work I added r1844393. Both, r1844389
>> and r1844393 are part of the /perl/Apache-Test/trunk/ external which
>> gets pulled into our test framework.
>>
>> Am 20.10.2018 um 06:28 schrieb Rainer Jung:
>>> Am 19.10.2018 um 23:31 schrieb Yann Ylavic:
>>>> Could not make the test suite framework work with 1.1.1 (cpan -u
>>>> didn't help).
>>>> Although the ssl tests report SUCCESS, httpd actually timeouts on
>>>> SSL_peek() (as already reported).
>>>
>>> Indeed I checked my test suite logs and until now all tests only used
>>> TLS 1.2. But what works for me now with TLS 1.3 is:
>>>
>>> - small fix in TestSSLCA.pm (r1844389), otherwise the geneated
>>> t/conf/ssl/ssl.conf always contains "SSLProtocol all -TLSv1.3"
>>> instead of "all" (unless you specifiy -sslproto explicitly).
>>>
>>> - Net::SSLeay 1.86_06 tag from Github
>>> https://github.com/radiator-software/p5-net-ssleay.git. Added "-ldl
>>> -pthread" to OTHERLDFLAGS in Makefile. It contains the plumbing
>>> needed for some new 1.1.1 APIs.
>>>
>>> - IO/Socket/SSL.pm recent version 2.060 plus patch
>>> https://github.com/noxxi/p5-io-socket-ssl/commit/e96b1c9e394011de4ee181cfa42b8021796bf7d4.patch
>>> (probably not needed) plus anti-hang patch to call
>>> Net::SSLeay::CTX_set_post_handshake_auth()
>>>
>>> --- IO/Socket/SSL.pm.orig 2018-08-15 18:03:29.000000000 +0000
>>> +++ IO/Socket/SSL.pm 2018-09-19 16:37:46.450281000 +0000
>>> @@ -2594,6 +2594,10 @@
>>> "Failed to load key from file (no PEM or DER)");
>>> }
>>>
>>> + if ($havecert && $havekey &&
>>> Net::SSLeay::OPENSSL_VERSION_NUMBER() >= 0x1010100f) {
>>> + Net::SSLeay::CTX_set_post_handshake_auth($ctx, 1);
>>> + }
>>> +
>>> # replace arg_hash with created context
>>> $ctx{$host} = $ctx;
>>> }
>>>
>>> The PHA patch was stolen from Joe's explanation of the PHA issue.
>>>
>>> With this setup, I can see some TLSv1.3 entries in the
>>> t/logs/ssl_request_log. For instance when running t/ssl/varlookup.t.
>>>
>>> Regards,
>>>
>>> Rainer
Re: Test suite and OpenSSL 1.1.1
Posted by Rainer Jung <ra...@kippdata.de>.
I now also added r1844396 to allow setting the CA for peer cert
verification and used it in echo.t and nttp-like.t to unbreak their ssl
testing (r1844397).
I didn't find more uses of the raw sockets.
Regards,
Rainer
Am 20.10.2018 um 08:47 schrieb Rainer Jung:
> To make the raw TLS socket tests work I added r1844393. Both, r1844389
> and r1844393 are part of the /perl/Apache-Test/trunk/ external which
> gets pulled into our test framework.
>
> Am 20.10.2018 um 06:28 schrieb Rainer Jung:
>> Am 19.10.2018 um 23:31 schrieb Yann Ylavic:
>>> Could not make the test suite framework work with 1.1.1 (cpan -u
>>> didn't help).
>>> Although the ssl tests report SUCCESS, httpd actually timeouts on
>>> SSL_peek() (as already reported).
>>
>> Indeed I checked my test suite logs and until now all tests only used
>> TLS 1.2. But what works for me now with TLS 1.3 is:
>>
>> - small fix in TestSSLCA.pm (r1844389), otherwise the geneated
>> t/conf/ssl/ssl.conf always contains "SSLProtocol all -TLSv1.3" instead
>> of "all" (unless you specifiy -sslproto explicitly).
>>
>> - Net::SSLeay 1.86_06 tag from Github
>> https://github.com/radiator-software/p5-net-ssleay.git. Added "-ldl
>> -pthread" to OTHERLDFLAGS in Makefile. It contains the plumbing needed
>> for some new 1.1.1 APIs.
>>
>> - IO/Socket/SSL.pm recent version 2.060 plus patch
>> https://github.com/noxxi/p5-io-socket-ssl/commit/e96b1c9e394011de4ee181cfa42b8021796bf7d4.patch
>> (probably not needed) plus anti-hang patch to call
>> Net::SSLeay::CTX_set_post_handshake_auth()
>>
>> --- IO/Socket/SSL.pm.orig 2018-08-15 18:03:29.000000000 +0000
>> +++ IO/Socket/SSL.pm 2018-09-19 16:37:46.450281000 +0000
>> @@ -2594,6 +2594,10 @@
>> "Failed to load key from file (no PEM or DER)");
>> }
>>
>> + if ($havecert && $havekey &&
>> Net::SSLeay::OPENSSL_VERSION_NUMBER() >= 0x1010100f) {
>> + Net::SSLeay::CTX_set_post_handshake_auth($ctx, 1);
>> + }
>> +
>> # replace arg_hash with created context
>> $ctx{$host} = $ctx;
>> }
>>
>> The PHA patch was stolen from Joe's explanation of the PHA issue.
>>
>> With this setup, I can see some TLSv1.3 entries in the
>> t/logs/ssl_request_log. For instance when running t/ssl/varlookup.t.
>>
>> Regards,
>>
>> Rainer
Re: Test suite and OpenSSL 1.1.1
Posted by Rainer Jung <ra...@kippdata.de>.
To make the raw TLS socket tests work I added r1844393. Both, r1844389
and r1844393 are part of the /perl/Apache-Test/trunk/ external which
gets pulled into our test framework.
Regards,
Rainer
Am 20.10.2018 um 06:28 schrieb Rainer Jung:
> Am 19.10.2018 um 23:31 schrieb Yann Ylavic:
>> Could not make the test suite framework work with 1.1.1 (cpan -u
>> didn't help).
>> Although the ssl tests report SUCCESS, httpd actually timeouts on
>> SSL_peek() (as already reported).
>
> Indeed I checked my test suite logs and until now all tests only used
> TLS 1.2. But what works for me now with TLS 1.3 is:
>
> - small fix in TestSSLCA.pm (r1844389), otherwise the geneated
> t/conf/ssl/ssl.conf always contains "SSLProtocol all -TLSv1.3" instead
> of "all" (unless you specifiy -sslproto explicitly).
>
> - Net::SSLeay 1.86_06 tag from Github
> https://github.com/radiator-software/p5-net-ssleay.git. Added "-ldl
> -pthread" to OTHERLDFLAGS in Makefile. It contains the plumbing needed
> for some new 1.1.1 APIs.
>
> - IO/Socket/SSL.pm recent version 2.060 plus patch
> https://github.com/noxxi/p5-io-socket-ssl/commit/e96b1c9e394011de4ee181cfa42b8021796bf7d4.patch
> (probably not needed) plus anti-hang patch to call
> Net::SSLeay::CTX_set_post_handshake_auth()
>
> --- IO/Socket/SSL.pm.orig 2018-08-15 18:03:29.000000000 +0000
> +++ IO/Socket/SSL.pm 2018-09-19 16:37:46.450281000 +0000
> @@ -2594,6 +2594,10 @@
> "Failed to load key from file (no PEM or DER)");
> }
>
> + if ($havecert && $havekey &&
> Net::SSLeay::OPENSSL_VERSION_NUMBER() >= 0x1010100f) {
> + Net::SSLeay::CTX_set_post_handshake_auth($ctx, 1);
> + }
> +
> # replace arg_hash with created context
> $ctx{$host} = $ctx;
> }
>
> The PHA patch was stolen from Joe's explanation of the PHA issue.
>
> With this setup, I can see some TLSv1.3 entries in the
> t/logs/ssl_request_log. For instance when running t/ssl/varlookup.t.
>
> Regards,
>
> Rainer
Re: Test suite and OpenSSL 1.1.1
Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, Oct 20, 2018 at 6:28 AM Rainer Jung <ra...@kippdata.de> wrote:
>
> - Net::SSLeay 1.86_06 tag from Github
> https://github.com/radiator-software/p5-net-ssleay.git. Added "-ldl
> -pthread" to OTHERLDFLAGS in Makefile. It contains the plumbing needed
> for some new 1.1.1 APIs.
With this change (and all the others checked out with test suite),
everything works for me.
(Actually I had to s/1.86_06/1.86/g at several places in p5-net-ssleay
to avoid 'Argument "1.86_06" isn't numeric in numeric lt (<) at
/usr/local/share/perl/5.26.2/IO/Socket/SSL.pm line 94' from test
suite).
Thanks Rainer!
Regards,
Yann.
Test suite and OpenSSL 1.1.1
Posted by Rainer Jung <ra...@kippdata.de>.
Am 19.10.2018 um 23:31 schrieb Yann Ylavic:
> Could not make the test suite framework work with 1.1.1 (cpan -u didn't help).
> Although the ssl tests report SUCCESS, httpd actually timeouts on
> SSL_peek() (as already reported).
Indeed I checked my test suite logs and until now all tests only used
TLS 1.2. But what works for me now with TLS 1.3 is:
- small fix in TestSSLCA.pm (r1844389), otherwise the geneated
t/conf/ssl/ssl.conf always contains "SSLProtocol all -TLSv1.3" instead
of "all" (unless you specifiy -sslproto explicitly).
- Net::SSLeay 1.86_06 tag from Github
https://github.com/radiator-software/p5-net-ssleay.git. Added "-ldl
-pthread" to OTHERLDFLAGS in Makefile. It contains the plumbing needed
for some new 1.1.1 APIs.
- IO/Socket/SSL.pm recent version 2.060 plus patch
https://github.com/noxxi/p5-io-socket-ssl/commit/e96b1c9e394011de4ee181cfa42b8021796bf7d4.patch
(probably not needed) plus anti-hang patch to call
Net::SSLeay::CTX_set_post_handshake_auth()
--- IO/Socket/SSL.pm.orig 2018-08-15 18:03:29.000000000 +0000
+++ IO/Socket/SSL.pm 2018-09-19 16:37:46.450281000 +0000
@@ -2594,6 +2594,10 @@
"Failed to load key from file (no PEM or DER)");
}
+ if ($havecert && $havekey &&
Net::SSLeay::OPENSSL_VERSION_NUMBER() >= 0x1010100f) {
+ Net::SSLeay::CTX_set_post_handshake_auth($ctx, 1);
+ }
+
# replace arg_hash with created context
$ctx{$host} = $ctx;
}
The PHA patch was stolen from Joe's explanation of the PHA issue.
With this setup, I can see some TLSv1.3 entries in the
t/logs/ssl_request_log. For instance when running t/ssl/varlookup.t.
Regards,
Rainer
Re: [VOTE] Release httpd-2.4.37
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Oct 18, 2018 at 4:36 PM Daniel Ruggeri <dr...@primary.net> wrote:
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.37:
+1: It's not just good, it's good enough!
Tested on Debian(s) both with openssl-1.1.0 (system) and openssl-1.1.1
(compiled).
Could not make the test suite framework work with 1.1.1 (cpan -u didn't help).
Although the ssl tests report SUCCESS, httpd actually timeouts on
SSL_peek() (as already reported).
So I also made "real" tests (including h2) with compatible clients
(curl, firefox) and everything worked as expected.
The lights are green for me, thanks everybody for the hard work on
mod_ssl and h2, and of course Daniel for RMing.
Re: [VOTE] Release httpd-2.4.37
Posted by Christophe JAILLET <ch...@wanadoo.fr>.
Le 18/10/2018 à 16:36, Daniel Ruggeri a écrit :
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.37:
> [X] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
> sha256:
> aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
> *httpd-2.4.37.tar.gz
>
+1
Tested on Ubuntu 18.10. gcc 8.1.0; openssl 1.1.1, event MPM.
CJ
Re: [VOTE] Release httpd-2.4.37
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Dennis,
Am 22.10.2018 um 02:15 schrieb Dennis Clarke:
> On 10/21/2018 08:03 PM, Rainer Jung wrote:
>> Am 18.10.2018 um 16:36 schrieb Daniel Ruggeri:
>>> Hi, all;
>>> Please find below the proposed release tarball and signatures:
>>> https://dist.apache.org/repos/dist/dev/httpd/
>>>
>>> I would like to call a VOTE over the next few days to release this
>>> candidate tarball as 2.4.37:
>>> [X] +1: It's not just good, it's good enough!
>>> [ ] +0: Let's have a talk.
>>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>>
>>> The computed digests of the tarball up for vote are:
>>> sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
>>> sha256:
>>> aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
>>> *httpd-2.4.37.tar.gz
>>
>
>> Built on
>>
>> - Solaris 10 Sparc as 32 Bit Binaries
>
> Amazing work. I have no idea what blazing fast hardware you are
> using to get this done. Special chemicals in the coffee port?
My Solaris hardware is really slow (V245) and building GCC and running
its test suite takes a few days here as well. Buiding httpd is much faster.
> I am still churning away on a fully 64-bit build and that means a
> toolchain update as well as a new gcc 8.2.0 thrown in to make some
> things more easy.
>
> No signs of daylight yet.
>
> However if it works as a 32-bit then hey should work as 64-bit? ;-)
You'll see ;)
Regards and thanks for testing,
Rainer
Re: [VOTE] Release httpd-2.4.37
Posted by Dennis Clarke <dc...@blastwave.org>.
On 10/21/2018 08:03 PM, Rainer Jung wrote:
> Am 18.10.2018 um 16:36 schrieb Daniel Ruggeri:
>> Hi, all;
>> Please find below the proposed release tarball and signatures:
>> https://dist.apache.org/repos/dist/dev/httpd/
>>
>> I would like to call a VOTE over the next few days to release this
>> candidate tarball as 2.4.37:
>> [X] +1: It's not just good, it's good enough!
>> [ ] +0: Let's have a talk.
>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>
>> The computed digests of the tarball up for vote are:
>> sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
>> sha256:
>> aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
>> *httpd-2.4.37.tar.gz
>
> Built on
>
> - Solaris 10 Sparc as 32 Bit Binaries
Amazing work. I have no idea what blazing fast hardware you are
using to get this done. Special chemicals in the coffee port?
I am still churning away on a fully 64-bit build and that means a
toolchain update as well as a new gcc 8.2.0 thrown in to make some
things more easy.
No signs of daylight yet.
However if it works as a 32-bit then hey should work as 64-bit? ;-)
Dennis
[1] https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02809.html
that took 36 hours ... sorry for the delay
Re: [VOTE] Release httpd-2.4.37
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.10.2018 um 16:36 schrieb Daniel Ruggeri:
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.37:
> [X] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
> sha256: aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
> *httpd-2.4.37.tar.gz
+1 to release and thanks a ton for RM!
Summary: all OK except for
- the CVE-2009-3555.t test with OpenSSL 1.1.1
- some shutdown crashes on Solaris event when statically linked
Detailed report:
- Sigs and hashes OK
- contents of tarballs identical
- contents of tag and tarballs identical
except for expected deltas
Built on
- Solaris 10 Sparc as 32 Bit Binaries
- SLES 11+12 (64 Bits)
- RHEL 6+7 (64 Bits)
For all platforms built
- with default (shared) and static modules
- with module set reallyall
- using --enable-load-all-modules
- against external APR/APU 1.6.5/1.6.1
- using external libraries
- expat 2.2.6
- pcre 8.42
- lua 5.3.5 (compiled with LUA_COMPAT_MODULE)
- distcache 1.5.1
- libxml2 2.9.8
- libnghttp2 1.33.0
- brotli 1.0.6
- curl 7.61.1
- jansson 2.11
and
- openssl 0.9.8zh, 1.0.2p, 1.0.2, 1.0.1e, 1.0.1i, 1.1.1
- Tool chain:
- platform gcc except on Solaris
(gcc 8.2.0 Solaris 10)
- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
- on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE,
-D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__
and -D_XPG6
All of the 216 builds succeeded.
- compiler warnings: none
Tested for
- Solaris 10, SLES 11+12, RHEL 6+7
- MPMs prefork, worker, event
- prefork skipped on Solaris due to the accept lock problem that
leads to timeouts and thus excessive testing times in the proxy
- default and static module builds
- log level trace8
- module set reallyall
- for "reallyall" 128 modules plus MPMs
- Perl client bundle build against OpenSSL 1.1.1, 1.1.0i, 1.0.2p and 0.9.8zh
- OpenSSL linked statically and as shared library
Every OpenSSL version in the client tested with every version in the
server, not just the same version. Client and server both with OpenSSL
1.1.1 really resulted in TLS 1.3 being used in most SSL tests (after
patching the test framework, all patches are committed to svn).
The total number of test suite runs was 1178.
The following test failures were seen:
a Crashes only on Solaris and only with event MPM and static builds.
The crash seems to happen only at the end of a process, likely due
to double cleanup of OpenSSL.
b Test 154 of t/modules/include.t only and always on
Solaris.
Not a regression
Old analysis was:
This is due to a bug in the test, which uses strftime()
with a "%s" pattern that is not supported on Solaris.
Until recently the server and the test client both returned
verbatim "%s" and the test succeeded. After updating some
Perl modules for the http2 tests, the perl client even
on Solaris now supports "%s" in strftime and the test starts
to fail. It seems we have to fix the test.
c Various tests in t/apache/expr_string.t
Not a regression.
Test numbers : 6, 11, 14, 17, 20, 23, 26, 29
Happens for 47 out of about 1100 runs
(once on SLES 11, once on Solaris 10, otherwise always on RHEL6).
The failure is always on line 87, where the error_log contents
are checked. Could be due to logs written to NFS.
d Test 5 in t/modules/dav.t:
Not a regression.
Only once, this time on SLES 11.
Creation, modified and now times not in the correct order.
This seems to be a system issue, all tests done on NFS,
many tested on virtualized guests.
e I expect prefork on Solaris still to observe timeouts during
proxy tests like reported for previous versions, but didn't test
it this time due to the long test runs when the problem happens.
I started these runs right now just to be able to report,
whether the old problem is still there or has changed.
f t/security/CVE-2009-3555.t
Fails in two ways:´, the first one I am unsure about the
criticality:
- When using OpenSSL 1.1.1 in client and server, it fails
in test 4, because the attacker request actually gets processed.
For the classic pre-1.3 handshake, there's special handling
to close the connection before the attacker request gets
handled. I am not 100% sure, but it looks to me, as if this
protection is only needed if the OpenSSL library itself is not
fixed against CVE-2009-3555 as an application side workaround.
So this should not be relevant for OpenSSL 1.1.1, and instead the
test s broken there. It would be nice if this opinion
could be confirmed by others. See the CVE-2009-3555 mail thread.
- For other OpenSSL versions fails in test 3 after switching the
test suite from Net::SSL to IO::Socket::SSL. These failures are
due to interop problems between Apache::TestRequest and
IO::Socket::SSL but should be fixed by my last adjustments to
Apache::TestRequest. So these are false positives.
g t/modules/http2.t fails for client or server using OpenSSL 0.9.8(zh)
False positive.
Success is not expected for these, but they are not excluded
from running the test. I committed an exclusion for client side
OpenSSL < 1.0.0 now and have a somewhat clumsy solution for exluding
the test when the server runs on OpenSSL < 1.0.0.
h t/ssl/proxy.t once failed in test 165 on Solaris
Not observed before but extremely rare.
The actual response as a 502 instead of 200.
Will be hard to diagnose due to its non-reproducibility.
IMHO not a show-stopper.
i t/modules/buffer.t
New test.
Fails due to the perl client stopping to send more data
as soon as the first reflected bytes are received. List discussion
indicates, that sending response bytes before the end of the request
body might not be spec compliant and thus the test be a false
positive.
So apart from the CVE-2009-3555 failure for OpenSSL 1.1.1 and the
shutdown crashes on Solaris no real problems. I think CVE-2009-3555 is a
false positive and the Solaris shutdown problem is not critical, because
only for event plus static build (plus probably APU crypto enabled).
Regards,
Rainer