The `security_level` stream option is only available as of OpenSSL
1.1.0, so we only set it for these versions. Older OpenSSL versions
do not have security levels at all.
This migrates all the tests using ext/openssl/tests/streams_crypto_method.pem
to the certificate generator, so we can easily adjust needed parameters.
In particular, this makes the cert security level 2 compatible.
However, we still need to downgrade security_level to 1 in a number
of tests, because they are testing TLS < 1.2 connections.
Saw a spurious failure from this one on azure macos, presumably
the process got interrupted in the middle and waited for more than
one second to resume.
After looking a bit more closely, this test doesn't actually test
what bug #48187 reported, because there is no DateTime::diff()
anywhere to be found. This test was also added speculatively,
because the root cause was never diagnosed, and the problems seems
to have resolved itself at some point.
As such, I'm simply dropping this test, rather than figuring out
how to make it more robust.
This makes the generated certificates compatible with security
level 2, which is apparently the default on Ubuntu 20.04.
Unfortunately this does not fix all tests, because some are using
pre-generated certificates.
Even if the length of a maker note does not match our expectations
(either because the maker note is corrupted, or because our
expectations do not quite match reality), there is no need to let
parsing fail; we can still go on parsing the other meta information.
Exception should be thrown before the db handle is destroyed.
The backtrace excerpt
==26628== Invalid read of size 4
==26628== at 0x53C49E3: sqlite3_errmsg (in /usr/lib64/libsqlite3.so.0.8.6)
==26628== by 0x38C4E9: zim_sqlite3_open (sqlite3.c:142)
==26628== by 0x8977BF: ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER (zend_vm_execute.h:1618)
==26628== by 0x8F801E: execute_ex (zend_vm_execute.h:53824)
==26628== by 0x8FC0BB: zend_execute (zend_vm_execute.h:57920)
==26628== by 0x828F54: zend_execute_scripts (zend.c:1672)
==26628== by 0x793C2C: php_execute_script (main.c:2621)
==26628== by 0x8FEA44: do_cli (php_cli.c:964)
==26628== by 0x8FF9DC: main (php_cli.c:1359)
Signed-off-by: Anatol Belski <ab@php.net>
The output normalization of bless_tests.php only detected absolute Unix
filenames; we extend this for absolute Windows filenames, regardless of
the platform we're running on (tests may have been run on Windows, but
bless_tests.php may be run from WSL or a Linux VM, for instance).
In module startup stage, we should not initiliaze
EG(modified_ini_directives) as it use zend MM, the zend MM will be
restart at the end of modules startup stage,
by say "partial", because this issue still exists if altering ZEND_USER
inis, we should add a zend_ini_deactive at the end of modules startup
stage, but it brings some new cost, and I think no one would do things
like that
The `timercmp()` manpage[1] points out that some systems have a broken
implementation which does not support `>=`. This is definitely the
case for the Windows SDK, which only supports `<` and `>`.
[1] <https://linux.die.net/man/3/timercmp>
If the current character is a line break character, it cannot be a tab
or space character, so we would always fail with an invalid sequence
error. Obviously, these `scan_stat == 4` conditions are meant to be
exclusive.
Furthermore, if `in_pp == NULL || in_left_p == NULL` is true, we hit a
segfault if we are not returning right away. Obviously, the additional
constraints don't make sense, so we remove them.
Extend configure.ac to accept PHP_UNAME as env variable to set the value of the
PHP_UNAME define in a reproducible manner. This allows distributions to set a
fixed value for php_uname and keep the default behaviour if PHP_UNAME is not
set.
Motivation: https://reproducible-builds.org/
Closes GH-5671.
Currently ./configure --enable-phar --program-suffix=7.4 will
result in binaries named php7.4 and phar but should instead
result in php7.4 and phar7.4
Closes GH-5650.
