* uri: Rename `uri_recomposition_mode_t` to `php_uri_recomposition_mode`
* uri: Align the names of the `php_uri_recomposition_mode` values
* uri: Rename `uri_component_read_mode_t` to `php_uri_component_read_mode`
* uri: Align the names of the `php_uri_component_read_mode` values
* uri: Rename `uri_property_name_t` to `php_uri_property_name`
* uri: Align the names of the `php_uri_property_name` values
* uri: Rename `uri_property_handler_t` to `php_uri_property_handler`
* uri: Rename `uri_(read|write)_t` to `php_uri_property_handler_(read|write)`
* uri: Rename `php_uri_property_handler`’s `(read|write)_func` to `read|write`
The `_func` is implied by the data type and the name of the struct.
* uri: Rename `uri_parser_t` to `php_uri_parser`
* uri: Shorten the names of `php_uri_parser` fields
The `_uri` suffix is implied, because this is an URI parser.
By using the `zend_hash_*()` functions directly, we can benefit from the
precalculated hash value in the given `zend_string *uri_parser_name`. We need
to deconstify the parameter, since the function might calculate the hash, thus
modifying the `zend_string*`.
Instead of
* adding a zval on the stack
* initializing it
* copying the value to the attribute
Just initialize the value directly in the zend_attribute_arg
For attributes, relying on the ref_map doesn't make sense the first
place as you can't really refer to attributes from attributes.
The code therefore assumes that the node is unique, which is broken.
Closes GH-19181.
Have each of the specialized methods for registering a constant return a
pointer to the registered constant the same way that the generic
`zend_register_constant()` function does, and use those in the generated
arginfo files to avoid needing to search for a constant that was just
registered in order to add attributes to it.
The code is already looking up the entry in the function table anyway,
so might as well use it directly.
This simplifies the code and avoids a redundant lookup.
* PHP-8.4:
Fix GH-18990, bug #81029, bug #47314: SOAP HTTP socket not closing on object destruction
Fix leak when path is too long in ZipArchive::extractTo()
curl: Remove incorrect string release on error
* PHP-8.3:
Fix GH-18990, bug #81029, bug #47314: SOAP HTTP socket not closing on object destruction
Fix leak when path is too long in ZipArchive::extractTo()
curl: Remove incorrect string release on error
Currently the resource is attached to the object and its refcount is
increased. This means that the refcount to the resource is 2 instead of
1 as expected. A refcount of 2 is necessary in the current code because
of how the error handling works: by using convert_to_null() the resource
actually goes to rc_dtor_func(), dropping its refcount to 1. So on error
the refcount is correct.
To solve the issue, let `stream` conceptually be a borrow of the
resource with refcount 1, and just use ZVAL_NULL() to prevent calling
rc_dtor_func() on the resource.
Closes GH-19001.
Libxml versions prior to 2.13 cannot correctly handle a call to
xmlNodeSetName() with a name longer than 2G. It will leave the node
object in an invalid state with a NULL name. This later causes a NULL
pointer dereference when using the name during message serialization.
To solve this, implement a workaround that resets the name to the
sentinel name if this situation arises.
Versions of libxml of 2.13 and higher are not affected.
This can be exploited if a SoapVar is created with a fully qualified
name that is longer than 2G. This would be possible if some application
code uses a namespace prefix from an untrusted source like from a remote
SOAP service.
Co-authored-by: Niels Dossche <7771979+nielsdos@users.noreply.github.com>
Libxml versions prior to 2.13 cannot correctly handle a call to
xmlNodeSetName() with a name longer than 2G. It will leave the node
object in an invalid state with a NULL name. This later causes a NULL
pointer dereference when using the name during message serialization.
To solve this, implement a workaround that resets the name to the
sentinel name if this situation arises.
Versions of libxml of 2.13 and higher are not affected.
This can be exploited if a SoapVar is created with a fully qualified
name that is longer than 2G. This would be possible if some application
code uses a namespace prefix from an untrusted source like from a remote
SOAP service.
Co-authored-by: Niels Dossche <7771979+nielsdos@users.noreply.github.com>
Only covers constants declared via stub files, others will be handled
separately in a later commit.
Does not include the intl extension, since that had some errors relating to the
cpp code; that extension will be updated separately.
* Deduplicate XML parsing code for SOAP
* Apply suggestions from code review
Co-authored-by: Gina Peter Banyard <girgias@php.net>
---------
Co-authored-by: Gina Peter Banyard <girgias@php.net>
`attr_is_equal_ex` makes no sense: attributes never inherit the
namespace of their element. Yet this is wrongly used as a combo for
checking both the node namespace and attribute namespace.
Furthermore, not all nodes have the proper namespace check.
Fix all of this by reworking the helpers and auditing the calls to the
namespace helpers.
Closes GH-16320.
Closes bug #68576.
Closes GH-18697.
Niels Dossche