It looks like the config.w32 uses CHECK_HEADER_ADD_INCLUDE to add the include
path to libxml into the search path.
That doesn't happen in zend-test.
To add to the Windows trouble, libxml is statically linked in, ext/libxml can
only be built statically but ext/zend-test can be built both statically and
dynamically.
So the regression tests won't work in all possible configurations anyway on Windows.
All of this is no problem on Linux because it just uses dynamic linking
and pkg-config, without any magic.
Signed-off-by: Ben Ramsey <ramsey@php.net>
Fixes GHSA-3qrf-m4j2-pcrr.
To parse a document with libxml2, you first need to create a parsing context.
The parsing context contains parsing options (e.g. XML_NOENT to substitute
entities) that the application (in this case PHP) can set.
Unfortunately, libxml2 also supports providing default set options.
For example, if you call xmlSubstituteEntitiesDefault(1) then the XML_NOENT
option will be added to the parsing options every time you create a parsing
context **even if the application never requested XML_NOENT**.
Third party extensions can override these globals, in particular the
substitute entity global. This causes entity substitution to be
unexpectedly active.
Fix it by setting the parsing options to a sane known value.
For API calls that depend on global state we introduce
PHP_LIBXML_SANITIZE_GLOBALS() and PHP_LIBXML_RESTORE_GLOBALS().
For other APIs that work directly with a context we introduce
php_libxml_sanitize_parse_ctxt_options().
Fix it by extending the array sizes by one character. As the input is
limited to the maximum path length, there will always be place to append
the slash. As the php_check_specific_open_basedir() simply uses the
strings to compare against each other, no new failures related to too
long paths are introduced.
We'll let the DOM and XML case handle a potentially too long path in the
library code.
The libxml based XML functions accepting a filename actually accept
URIs with possibly percent-encoded characters. Percent-encoded NUL
bytes lead to truncation, like non-encoded NUL bytes would. We catch
those, and let the functions fail with a respective warning.
The test contains PII in the base64-encoded part and is way too
complicated to be useful. I'd try to reduce it, but I can't tell
what it's actually supposed to test.
This version of libxml introduced quite a few changes. Most of
them are differences in error reporting, while some also change
behavior, e.g. null bytes are no longer supported and xinclude
recursion is limited.
Closes GH-7030. Closes GH-7046.
Co-authored-by: Nikita Popov <nikic@php.net>
According to the DOM standard, elements may only contain element, text,
processing instruction and comment nodes[1]. It is also specified that
a HierarchyRequestError should be thrown if a document is to be
inserted[2]. We follow that standard, and prevent the use-after-free
this way.
[1] <https://dom.spec.whatwg.org/#node-trees>
[2] <https://dom.spec.whatwg.org/#mutation-algorithms>
Closes GH-6765.
According to the DOM specification, this argument should be
nullable. It's also supposed to be a required argument, but
not changing that at this point.
This is an unavoidable breaking change to both the type and
parameter name.
The assertion that was supposed to prevent this was overly lax
and accepted any object type for string parameters.
libxml2 has no particular issues parsing HTML strings with NUL bytes;
these just cause truncation of the current text content, but parsing
continues generally. Since `::loadHTMLFile()` already supports NUL
bytes, `::loadHTML()` should as well.
Note that this is different from XML, which does not allow any NUL
bytes.
Closes GH-6368.
Not all extensions consistently throw exceptions when the user passes
a path name containing null bytes. Also, some extensions would throw
a ValueError while others would throw a TypeError. Error messages
also varied.
Now a ValueError is thrown after all failed path checks, at least for
as far as these occur in functions that are exposed to userland.
Closes GH-6216.
In preparation for generating method signatures for the manual.
This change gets rid of bogus false|null return types, a few unnecessary trailing backslashes, and settles on using ? when possible for nullable types.
From an engine perspective, named parameters mainly add three
concepts:
* The SEND_* opcodes now accept a CONST op2, which is the
argument name. For now, it is looked up by linear scan and
runtime cached.
* This may leave UNDEF arguments on the stack. To avoid having
to deal with them in other places, a CHECK_UNDEF_ARGS opcode
is used to either replace them with defaults, or error.
* For variadic functions, EX(extra_named_params) are collected
and need to be freed based on ZEND_CALL_HAS_EXTRA_NAMED_PARAMS.
RFC: https://wiki.php.net/rfc/named_params
Closes GH-5357.
