Before this commit, the result produced by a joaat hash depended
on how the input data was chunked. A hash produced by multiple
`hash_update` operations was incorrect. For example, this code,
which should produce three identical lines:
var_dump(hash("joaat", "abcd"));
$hash = hash_init("joaat");
hash_update($hash, "ab");
hash_update($hash, "cd");
var_dump(hash_final($hash));
$hash = hash_init("joaat");
hash_update($hash, "abc");
hash_update($hash, "d");
var_dump(hash_final($hash));
instead produced:
string(8) "cd8b6206"
string(8) "e590d137"
string(8) "2d59d087"
This is because the finalization step, involving shift operations
and adds, was applied on every chunk, rather than once at the end
as is required by the hash definition.
After this commit, the code above produces:
string(8) "cd8b6206"
string(8) "cd8b6206"
string(8) "cd8b6206"
as expected.
Some tests encoded the wrong behavior and were corrected.
Closes GH-5749
Check if data would overlap and also add an assert. Previous
implementations didn't have this issue, as the direct assignment was
used.
Signed-off-by: Anatol Belski <ab@php.net>
The existing AC_FPM_APPARMOR macro (which is always run when FPM is
enabled) checks for the existence of libapparmor, and adds it to $LIBS
if found. The result is an "automagic" dependency on libapparmor that
depends not only on the user's configuration, but also on the build
host's environment.
In particular, this can cause problems if the user just happens to
have libapparmor installed (for testing or development) when he builds
PHP. Later, he may remove libapparmor, not realizing that PHP depends
on it. At that point, FPM will cease to work due to the missing library.
This commit adds a new configure flag called "--with-fpm-apparmor",
defaulting to "no", that enables or disables the feature. The new flag
is used to signal the user's intent; whether or not he wants to use
AppArmor. If he does, then we still check for the existence and
usability of libapparmor; however, it is now an error for the library
to be missing when --with-fpm-apparmor is requested.
Gentoo-bug: https://bugs.gentoo.org/637402
PHP-bug: https://bugs.php.net/bug.php?id=75519
(int) $curlHandle will return spl_object_id($curlHandle). This
makes curl handle objects backwards compatible with code using
(int) $curlHandle to obtain a resource ID.
Closes GH-5743.
- Fix typo in build/php.m4
- Nothing uses HAVE_INTTYPES_H; so remove check for header file
- Nothing defines ZEND_ACCONFIG_H_NO_C_PROTOS; so remove #ifndef
- `format_money` was removed in 2019, so <monetary.h> no longer needed
- Nothing uses HAVE_NETDB_H; so remove check for header file
- Nothing checks HAVE_TERMIOS_H; so remove check for header file
(This was actually added when Wez Furlong was adding the original implementation of
PTY support in `proc_open`, since replaced.)
- Nothing checks HAVE_SYS_AUXV_H; so remove check for header file
- PHP_BUILD_DATE variable is not used for anything, so remove it
This variable was added to the Makefile, but from there, was not used for anything.
The comments suggest it was intended to allow 'reproducible builds'. Presumably,
this means that if a bug is found in a PHP binary somewhere, one could look at the
Makefile which it was built from, see the date, and then could check the same
code version out from source control. But... there can easily be multiple commits
to the repo in the same day. Also, what makes us think that the Makefile which a
binary was built from will be easily available?
Besides, ext/standard/info.c already embeds the build date and time in each binary...
but it does it using `__DATE__` and `__TIME__` (see `php_print_info`).
- Nothing checks HAVE_FINITE; so don't check for function
- Grammar fix to comment in build/php.m4
- Nothing sets $php_ldflags_add_usr_lib variable in configure, so remove conditional
This was added in 2002, when Rasmus was having difficulty building PHP on some
host and needed to have /usr/lib in the rpath. It was never documented and
probably has never been used by anyone else.
As discussed on GH-5632, the HTML functionality does not appear
to be in active use. For HTML rendering of test results, it is
suggested to instead use the JUnit integration, in combination
with your favorite JUnit viewer.
Closes GH-5705.
One of the weirdest pieces of PHP code I've ever seen. In terms
of tokens, this gets internally translated to
use x as y; echo as my_echo;
On master it crashes because this "echo" does not have attached
identifier metadata. Make sure it is added and then reject the
use of "<?=" as an identifier inside zend_lex_tstring.
Fixes oss-fuzz #23547.
These were XFAILed due to a bug in the log implementation that
caused intermittent failures. However, this issue is supposed to
be resolved in the meantime, so try dropping the XFAIL marker.
Nikita Popov