When PaX mprotect active, opcache JIT test fail as it needs
the PROT_MPROTECT macro to be able to allow further permission
promotion with mprotect.
Closes GH-5929.
This method was used to protect code against XXE processing attacks.
Since PHP now requires libxml >= 2.9.0 external entity loading no longer
needs to be disabled to prevent these attacks. It is disabled by default.
Also, the method has an unwanted side effect that causes a lot of
confusion: Parsing XML data from resources like files is no longer possible.
Closes GH-5867.
Since libxml version 2.9.0 external entity loading is disabled by default.
Bumping the version requirement means that XML processing in PHP is no
longer vulnerable to XXE processing attacks by default.
In other words, don't automatically unserialize when the magic
phar:// stream wrappers are used.
RFC: https://wiki.php.net/rfc/phar_stop_autoloading_metadata
Also, change the signature from `getMetadata()`
to `getMetadata(array $unserialize_options = [])`.
Start throwing earlier if setMetadata() is called and serialization threw.
See https://externals.io/message/110856 and
https://bugs.php.net/bug.php?id=76774
This was refactored to add a phar_metadata_tracker for the following reasons:
- The way to properly copy a zval was previously implicit and undocumented
(e.g. is it a pointer to a raw string or an actual value)
- Avoid unnecessary serialization and unserialization in the most common case
- If a metadata value is serialized once while saving a new/modified phar file,
this allows reusing the same serialized string.
- Have as few ways to copy/clone/lazily parse metadata (etc.) as possible,
so that code changes can be limited to only a few places in the future.
- Performance is hopefully not a concern - copying a string should be faster
than unserializing a value, and metadata should be rare in most cases.
Remove unnecessary skip in a test(Compression's unused)
Add additional assertions about usage of persistent phars
Improve robustness of `Phar*->setMetadata()`
- Add sanity checks for edge cases freeing metadata, when destructors
or serializers modify the phar recursively.
- Typical use cases of php have phar.readonly=1 and would not be affected.
Closes GH-5855
In practice, we always act as an HTTP/1.1 client, for compatibility
with servers which ignore protocol version. Sending the version in
the request will avoid problems with servers which don't ignore it.
HTTP/1.0 can still be forced using a stream context option.
Closes GH-5899.
Also fixes similar issues for DateTimeImmutable::createFromFormat,
DateTime::createFromImmmutable, DateTime::createFromInterface,
DateTimeImmutable::createFromMutable, and
DateTimeImmutable::createFromInterface.
Currently, it's possible to override `php -a`s completion
functionality to provide an alternative to the C implementation,
with `readline_completion_function()`.
However, that surprisingly gets overridden when called from
`auto_prepend_file`, because those scripts get run before the interactive shell
is started. I believe that not overriding it would be more consistent
with what happens when you override the completion function **after** the
interactive shell.
CLI is the only built-in API that uses this (See discussion in GH-5872).
I believe MINIT and RINIT will only run once when invoked with `php -a`.
Add documentation about the architecture of how php uses readline/libedit
Closes GH-5872
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.
Nikita Popov