| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
| |
not if they aren't in 5.4, too.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This reverts the following commits:
974324676b2436f159f42d9241c569f813471684
4662151ea7d7b6920d115cf2a2d6e9d4232727a3
84fe2cc890e49f40bac7c3ba74b3cfc6dc4cef2f
This does not revert the JSON changes released in PHP 5.3.14.
|
| | |
|
| |
|
|
| |
for successful XFAIL)
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| | |
Fixed a memory allocation bug in crypt() SHA256/512 that can
cause segmentation faults when passed in salts with a null byte
early.
|
| | |
| |
| |
| |
| | |
This replaces json_last_error(true) and is consistent with other custom
error handling functions.
|
| | |
| |
| |
| |
| | |
This fixes the same issue in multiple extensions. This isn't needed
in later branches as 5.4 introduced object_properties_init()
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
segfaul)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
ArrayIterator implemented Countable only after it was already inherited by
RecursiveArrayIterator. Thus the interface was missing in RAI.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
New 0.10.1 has a stronger archive integrity check. Restoring
the old behaviour of libzip < 0.10.1 makes no sense at this
place.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Travis will always build all branches. As we just have a .travis.yml
on master, travis will go ahead and checkout PHP-5.3. It fails and
then sends mails. We really don't want to get spammed, so we add
a .travis.yml that is just silent.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
