Use salt_len_in instead of strlen(salt) or PHP_MAX_SALT_LEN, otherwise too
much memory will be allocated.
sha512 has a 86 character checksum, not 43. That probably was a copy&paste
from the sha256 code which indeed has 43.
The allocation also was using sizeof(char *), thus allocating 4 or 8 times
as much memory as necessary. The sizeof(char *) was removed in the 5.4
branch in b7a92c9 but forgotten on 5.3.
The memset 0 call was using PHP_MAX_SALT_LEN which can be smaller than the
output buffer and thus not zeroing out everything. Use the size of the
output buffer (needed) instead.
json_encode() no longer throws warnings. Instead only the error code for
json_last_error() is set.
As it is hard to debug the error from just an error code an optional
$as_string parameter was added to json_last_error(), which returns an
error message instead of an error code.
base64_encode used safe_emalloc, but one of the arguments was derived from a
multiplication, thus making the allocation unsafe again.
There was a size check in place, but it was off by a factor of two as it
didn't account for the signedness of the integer type.
The unsafe allocation is not exploitable, but still causes funny behavior
when the sized overflows into a negative number.
To fix the issue the *4 factor is moved into the size argument (where it is
known to be safe), so safe_emalloc can carry out the multiplication.
The size check is removed as it doesn't really make sense once safe_emalloc
works correctly. (Would only cause base64_encode to silently return false
instead of throwing an error. Also could cause problems with other uses of
the base64 encoding API, which all don't check for a NULL return value.)
Furthermore the (length + 2) < 0 check is replaced with just length < 0.
Allowing lengths -2 and -1 doesn't make sense semantically and also is not
honored in the following code (negative length would access unallocated
memory.)
Actually the length < 0 check doesn't make sense altogether, but I left it
there just to be safe.
json_encode() now returns bool(false) for all possible errors, throws the
respective warning and also sets the respective json_last_error() error
code. Three new error codes have been added:
* JSON_ERROR_RECURSION
* JSON_ERROR_INF_OR_NAN
* JSON_ERROR_UNSUPPORTED_TYPE
To get a partial JSON output instead of bool(false) the option
JSON_PARTIAL_OUTPUT_ON_ERROR can be specified. In this case the invalid
segments will be replaced either by null (for recursion, unsupported type
and invalid JSON) or 0 (for Inf and NaN).
The warning for invalid UTF-8 stays intact and is thrown also with
display_errors = On. If this behavior is undesired this can be remedied
later.
Summary:
No easy way to put these in the hash extension since we don't really support optional
parameters to certain algorithms. Implemented in openssl for now since it has it already
and is pretty stable.
Only SHA1 is confirmed to work as an algorithm but openssl has a parameter so it can be
changed in the future.
Will backport to 5.4 potentially with Stas' approval.
Test Plan:
Ran newly added tests which came from RFC 6070
Custom extension segfaults during xmlParseFile with FPM SAPI
because the regular list is not prepared during the MINIT phase
and our custom external entity loader tries to open PHP streams.
* PHP-5.3:
zip windows fixes
fixed bc break related to #57905
fixed a bit overlooked from the last libzip port
brought the fix for #47667 back
fixed zip entry freeing
rechecked the merged libzip, took also the indents from the original to avoid confusion next time
fixed a double freeing crash
fixed header include
initial libzip upgrade patch to 0.10.1
- BFN
Conflicts:
NEWS
