Or on Windows it is going to use either FormatMessageW or strerror_s
for compatibility with previous error messages.
It also needs to accomodate for GNU and BSD versions of strerror_r
returning different type.
Closes GH-19251
Since the ini message handlers already check for basedir, we need to
drop the basedir check from ini_set. Then we also fix the exceptional
case for the empty string: it should bypass the basedir check.
Furthermore, there was a regression introduced with the error_log
"syslog" check in ddfe269a (inverted check), so we fix that as well.
Closes GH-19487
* 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.
* main: Ignore `register_argc_argv` when `SG(request_info).argc` is available
* sapi: Remove hardcoded `register_argc_argv` for CLI SAPIs
This INI is ignored since the previous commit, which makes the hardcoded
setting obsolete.
* main: Deprecate deriving $_SERVER['argc'] and $_SERVER['argv'] from the query string
RFC: https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_the_register_argc_argv_ini_directive
* main: Adjust deprecation message for `register_argc_argv`
* NEWS/UPGRADING
PSFS_FEED_ME is supposed to be returned when the filter did not receive
enough data and did not generate buckets for the output brigade.
The test generates buckets anyway on the output brigade, and the stream
layer did not handle that case causing a memory leak.
To solve this, discard any such buckets as it would conflict with the
status code returned by the filter. This keeps BC and solves the leak.
Closes GH-18972.
The string is converted twice for some reason.
This is pointless, and furthermore, this is observable in userspace code
when dealing with Stringable objects.
Closes GH-19713.
This one is not initialized. This is not hittable from userspace code
because all locations within first-party php-src code have a valid
`option` argument.
Closes GH-19714.
Use the PHP_STREAM_FLAG_NO_FCLOSE flag to prevent closing a stream while
a handler is running. We already do this in some other places as well.
Only handlers that do something with the stream afterwards need changes.
Closes GH-18797.
This reverts commit ca4a841921.
We like the error message change, but not the downgrade to notice
at this time in the release cycle.
@bukka will come back around
* Remove include "sanity check" to get a better error message
Instead of rejecting directories / non-regular files early with
a generic error, we should just accept them and error later when a
read is attempted. This is more general and will generate a better
error message on Linux. On Windows, the error remains the same as
before.
* Update error message to include include_path
fix format for include path
---------
Co-authored-by: Joe Watkins <krakjoe@php.net>
RFC: https://wiki.php.net/rfc/deprecations_php_8_5#remove_disable_classes_ini_setting
This took longer to merge than expected but the initial motivation from 2 years ago still applied:
As described in the email to the PHP internals list [1] this feature is fundamentally broken and pointless.
Only internal classes can be disable which brings the following observation. On a minimal build of PHP, with only the mandatory extensions enabled, there are 148 classes/interfaces/traits defined. [2]
Other than the SPL ones (and even then), disabling any of these classes will cause issues within the engine.
Moreover, the SPL ones are not a security concern.
Therefore, any other class that can be disabled must come from an extension that can be disabled altogether. And "disabling" a class from an extension without disabling said extension will render it useless anyway.
If a hosting provided is concerned about an extension, then it should not enable it in the first place. Not break it ad hoc.
Considering the above, I cannot see how this functionality was ever useful.
This is in stark contrast to the disable_functions INI setting, which can be used to selectively remove functionality of an extension without breaking it overall.
What makes this setting particularly broken is that it does not unregister the class, it only overwrites the create CE handler to emit a warning and purge the properties and function hashtables. This leads to various use after free, segfaults, and broken expectations for the engine and extensions which define said classes. On top of that, it is possible to actually instantiate such a class (and even classes which actually disallow this like ext/imap) in userland, and pass it to function that are typed against said class without raising a TypeError. However, when trying to do anything with said object stuff is going to explode in countless ways.
[1] https://news-web.php.net/php.internals/120896
[2] https://gist.github.com/Girgias/63d55ba1e50b580412b004046daed02b
This was initially introduced with https://github.com/php/php-src/commit/9f86cdaf7fc4
However, this should also have been done for the opendir call.
This omission was found via OSS-Fuzz 51047 [1]
and fixed in a more general way in d0b3096ff0
by resetting `FG(user_stream_current_filename)` at the end of the request during shutdown.
As such this zend_try/zend_catch block is now unnecessary.
[1]: https://issues.oss-fuzz.com/issues/42515581
