* PHP-8.1:
Fix GH-12223: Entity reference produces infinite loop in var_dump/print_r
Fix GH-12192: SimpleXML infinite loop when getName() is called within foreach
Fix GH-12186: segfault copying/cloning a finalized HashContext
The initialization routine for XXH3 was not prepared for exceptions from seed.
Fix this by using try_convert_to_string.
For discussion, please see: GH-10305
Closes GH-10352
Signed-off-by: George Peter Banyard <girgias@php.net>
We must not allow to serialize already finalized `HashContext`s, since
the internal context is already freed. Since there is not much point
in serializing finalized `HashContext`s, we just bail out in that case.
Closes GH-8265.
Like `hash_file()`, `hash_hmac_file()` expects a filename, and not some
string data. Fixing this now, constitutes a (hopefully small) BC break
though.
Closes GH-7828.
Deprecate mhash(), mhash_keygen_s2k(), mhash_count(),
mhash_get_block_size() and mhash_get_hash_name() in favor of the
normal hash_*() functions.
Part of https://wiki.php.net/rfc/deprecations_php_8_1.
A secret can be passed through the options array. The length is
currently in the range of 136 to 256 bytes. The concerned algos are
already marked as non serializable.
Signed-off-by: Anatol Belski <ab@php.net>
This deprecates passing null to non-nullable scale arguments of
internal functions, with the eventual goal of making the behavior
consistent with userland functions, where null is never accepted
for non-nullable arguments.
This change is expected to cause quite a lot of fallout. In most
cases, calling code should be adjusted to avoid passing null. In
some cases, PHP should be adjusted to make some function arguments
nullable. I have already fixed a number of functions before landing
this, but feel free to file a bug if you encounter a function that
doesn't accept null, but probably should. (The rule of thumb for
this to be applicable is that the function must have special behavior
for 0 or "", which is distinct from the natural behavior of the
parameter.)
RFC: https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg
Closes GH-6475.
The implementation bundles the xxHash v0.8.0 release and includes all the variants
- xxh32, 32-bit wide
- xxh64, 64-bit wide
- xxh3, 64-bit wide
- xxh128, 128-bit wide
An initial hash state can be passed through the options arrray. An additional
functionality not targeted in this implementation is the secret support in xxh3
and xxh128. That can be added at a later point.
The serialization for xxh3 and xxh128 should not be implemented, as the
state would contain the secret. Despite the xxHash is a non crypto
algorithm, the secret would be serialized as plain text which would be
insecure.
Closes GH-6524
Signed-off-by: Anatol Belski <ab@php.net>
The concrete need on this change is to support passing an initial seed
to the murmur hash. Passing a custom seed is important in terms of
randomizing the hash function.
The suggested implementation adds a HashTable parameter to all the
init callbacks. Further on, an array with custom arguments is accepted
from `hash` or `hash_init` from the user land. Currently several things
like `hash_hkdf` are not touched, as they don't need passing custom
args.
Some convenience macros have been added to the SHA/MD families of
functions, so the consuming code doesn't have to be changed widely.
Another way to implement this is to add another type of the init that
would accept a HT with arguments. However, that would still require
touching all the context structs in all the algos. That would also
increase the size of those structs. As an init function is called just
once, the way of modifying the existing init callback has been seen
as more preferrable.
Closes GH-6400.
Signed-off-by: Anatol Belski <ab@php.net>
Co-Developed-by: Nikita Popov <nikita.ppv@googlemail.com>
Signed-off-by: Nikita Popov <nikita.ppv@googlemail.com>
Acked-by: Michael Wallner <mike@php.net>
Reviewed-by: Máté Kocsis <kocsismate@woohoolabs.com>
Reviewed-by: Eddie Kohler <ekohler@gmail.com>
The implementation is based on the upstream PMurHash. The following
variants are implemented
- murmur3a, 32-bit hash
- murmur3c, 128-bit hash for x86
- murmur3f, 128-bit hash for x64
The custom seed support is not targeted by this implementation. It will
need a major change to the API, so then custom arguments can be passed
through `hash_init`. For now, the starting hash is always zero.
Fixes bug #68109, closes#6059
Signed-off-by: Anatol Belski <ab@php.net>
Co-Developed-by: Michael Wallner <mike@php.net>
Signed-off-by: Michael Wallner <mike@php.net>
Currently we treat paths with null bytes as a TypeError, which is
incorrect, and rather inconsistent, as we treat empty paths as
ValueError. We do this because the error is generated by zpp and
it's easier to always throw TypeError there.
This changes the zpp implementation to throw a TypeError only if
the type is actually wrong and throw ValueError for null bytes.
The error message is also split accordingly, to be more precise.
Closes GH-6094.
Based on:
"Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction"
V. Gopal, E. Ozturk, et al., 2009, http://intel.ly/2ySEwL0
Signed-off-by: Frank Du <frank.du@intel.com>
Closes GH-6018
* Modify php_hash_ops to contain the algorithm name and
serialize and unserialize methods.
* Implement __serialize and __unserialize magic methods on
HashContext.
Note that serialized HashContexts are not necessarily portable
between PHP versions or from architecture to architecture.
(Most are, though Keccak and slow SHA3s are not.)
An exception is thrown when an unsupported serialization is
attempted.
Because of security concerns, HASH_HMAC contexts are not
currently serializable; attempting to serialize one throws
an exception.
Serialization exposes the state of HashContext memory, so ensure
that memory is zeroed before use by allocating it with a new
php_hash_alloc_context function. Performance impact is
negligible.
Some hash internal states have logical pointers into a buffer,
or sponge, that absorbs input provided in bytes rather than
chunks. The unserialize functions for these hash functions
must validate that the logical pointers are all within bounds,
lest future hash operations cause out-of-bounds memory accesses.
* Adler32, CRC32, FNV, joaat: simple state, no buffer positions
* Gost, MD2, SHA3, Snefru, Tiger, Whirlpool: buffer positions
must be validated
* MD4, MD5, SHA1, SHA2, haval, ripemd: buffer positions encoded
bitwise, forced to within bounds on use; no need to validate
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
