#externals

[VOTE] [RFC] Case-insensitive extension names in ini_get_all()

Mon, 02 Nov 2026 02:47:21 +0000

Hi all,

The voting process of the Case-insensitive extension names in ini_get_all()
RFC starts today and ends at Nov 16 00:00:00 UTC.

RFC: https://wiki.php.net/rfc/case_insensitive_ini_get_all
Discussion thread: https://externals.io/message/132226, https://news-web.php.net/php.internals/132875

Thank you,
Weilin Du

[RFC] [VOTE] Throw exception for invalid characters in number base functions

Sun, 01 Nov 2026 19:49:53 +0000

It is now possible to vote on the RFC "Throw exception for invalid characters in number base functions".

RFC: https://wiki.php.net/rfc/throw_error_for_invalid_characters_for_number_base

This RFC was accepted with 27 yes votes and 1 no vote.

Regards,

Sjoerd Langkemper

[RFC] PDO binary parameter support

Sun, 01 Nov 2026 16:39:20 +0000

Hi Calvin,

Here are a couple of follow-up notes.

The fallback leaves each driver to choose STR or LOB, and STR
corrupts data: pdo_pgsql reads text-format parameters as C strings
(truncated at the first NUL), pdo_mysql loses the _binary introducer. A
per-driver table (native bind, emulated quote, fetch) would pin this down.

For drivers that use emulated prepares, perhaps we could check string
contents instead and use binary quoting based on that, but that feels slow
and what characters need binary quoting would differ per driver.

Content sniffing can't settle this. A bytea or varbinary value can be valid
text, and text can contain a NUL, so the driver has to be told. It also
doesn't help native prepares: pdo_pgsql sends text-format parameters as C
strings, so they truncate at the first NUL regardless of quoting. That's
the strongest argument for the RFC imho.

Neither representation degrades safely. An unknown type 6 falls to
text in the bundled drivers and pdo_oci, IM001 in pdo_ibm, and a fatal
error in pdo_sqlsrv. A flag only survives where the type is masked with
PDO_PARAM_TYPE(); the emulated-prepare parser, PDO::quote(), the pgsql
quoter, fetch_value() and pdo_sqlsrv all compare the raw value. The flag
works only if core masks it before quoting and fetch overrides; the RFC
should require that, and define what PARAM_INT | PARAM_BINARY does
(ValueError, I'd say).

Marking this a breaking change for drivers seems reasonable then

The driver break decides between using a type versus a flag. A new type 6
is a fatal error in pdo_sqlsrv and IM001 in pdo_ibm until each driver ships
an update. A flag that core masks before quoting allows fetch to fall back
to STR/LOB in any driver that ignores it. I'd go with the flag, and
reject combinations
with INT/BOOL/NULL with a ValueError.

Changing getColumnMeta()'s pdo_type breaks strict comparisons either
way (6 or STR | BINARY). A separate key would avoid that.

I suspect a BC break for things relying on getColumnMeta would happen
regardless of strategy. We could try something like pdo_sqlite's blob key
perhaps if we really want to avoid it.

pdo_sqlite already marks blobs in getColumnMeta()'s "flags" array, which is
a good precedent for leaving pdo_type alone.

--
Ilia Alshanetsky
Technologist, CTO, Entrepreneur
E: ilia@ilia.ws
T: @iliaa
B: http://ilia.ws

[RFC] Scope

Sun, 01 Nov 2026 14:31:26 +0000

I did go back and forth with terminology, but eventually landed on Scope. The term is used elsewhere in php documentation, for example Closure::bind() etc, but context is used much more.

fiber-interop/api on packagist has a Scope polyfill, and I don't think personally that WeakMap was hard to get right for scoped services. It takes getting used to, but it seems better than storing data directly in the scope object.

With regards,
Frode Børli

Sendt fra Outlook for iOShttps://aka.ms/o0ukef

From: Rowan Tommins [IMSoP] imsop.php@rwec.co.uk
Sent: Sunday, 01 November 2026 15:26:40
To: internals@lists.php.net internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Scope

Hi internals,

I'd like to start the discussion on a new RFC:

https://wiki.php.net/rfc/scope

Hi Frode,

I'm really happy to see this as an independent, focussed, RFC, which can hopefully fit well with the other async-related proposals being worked on.

In early versions of the "True Async" RFC, Edmond Dantes included a complex API for attaching data to coroutine scopes, and I argued at the time that it could be simplified, and more complex structures built on top of it later. It looks like that's exactly the approach taken here, providing only the parts that are essentially impossible in userland.

I do share Larry's concern that some of the common patterns using WeakMap will be hard to get right, but maybe that can be solved by additional helper classes and functions which might have other uses anyway?

The only slightly trivial reaction I had was to the name: variable scope is something we talk about so often, that I can see "variables tied to the current Scope" confusing people. Naming things is notoriously hard, but I note that a lot of the other languages you reference use the word "context" instead, and wonder if you'd considered that?

Thanks,

--
Rowan Tommins
[IMSoP]

[RFC] Scope

Sun, 01 Nov 2026 14:26:40 +0000

Hi internals,

I'd like to start the discussion on a new RFC:

https://wiki.php.net/rfc/scope https://wiki.php.net/rfc/scope

Hi Frode,

I'm really happy to see this as an independent, focussed, RFC, which can
hopefully fit well with the other async-related proposals being worked on.

In early versions of the "True Async" RFC, Edmond Dantes included a
complex API for attaching data to coroutine scopes, and I argued at the
time that it could be simplified, and more complex structures built on
top of it later. It looks like that's exactly the approach taken here,
providing only the parts that are essentially impossible in userland.

I do share Larry's concern that some of the common patterns using
WeakMap will be hard to get right, but maybe that can be solved by
additional helper classes and functions which might have other uses anyway?

The only slightly trivial reaction I had was to the name: variable scope
is something we talk about so often, that I can see "variables tied to
the current Scope" confusing people. Naming things is notoriously hard,
but I note that a lot of the other languages you reference use the word
"context" instead, and wonder if you'd considered that?

Thanks,

--
Rowan Tommins
[IMSoP]

[RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

Sun, 01 Nov 2026 11:19:38 +0000

The section on “bcrypt-sha256” is very vague in how your construction
is better. Given that both bcrypt-sha256 and your bcrypt-wrap (with
SHA-512) use a HMAC construction using the (BCrypt) salt as a key as the
pre-hash, folks will rightfully wonder how the bcrypt-wrap construction
is better than that of bcrypt-sha256 (other than using a different hash
function) and should not be required to “reverse engineer” the
differences.

Recently two new password hashes were proposed, both with the goal of solving bcrypt's 72-byte limit and failure to handle null-bytes:

PASSWORD_BCRYPT_WRAP https://wiki.php.net/rfc/password_bcrypt_wrap
PASSWORD_BCRYPT_SHA256 https://wiki.php.net/rfc/bcrypt_sha256 (proposed by me)

Both prehash the password before passing them to bcrypt.
• BCRYPT_SHA256 uses the same algorithm as Python's passlib. That provides interoperability with that library. It also means we cannot deviate from that algorithm without giving up that interoperability.
• BCRYPT_SHA256 is simpler and adds less code to PHP.
• BCRYPT_WRAP supports two prehashing algorithms.
• Both use the salt as the key, but in a technically different way. BCRYPT_WRAP decodes the base64-encoded salt, BCRYPT_SHA256 normalizes the text version of the salt.
• The text representation of the hash differs: BCRYPT_WRAP follows the PHC string format and is slightly longer than BCRYPT_SHA256.
I think both RFC with all three proposed prehashing methods are sufficiently secure. For security I see no reason to prefer one over the other.

Adding one new algorithm would be sufficient. Cryptographic agility within the hashing algorithm is not necesssary; users can move to another hashing algorithm such as Argon2. Both hash formats have a version field, making it possible to make backwards compatible changes.

It is unfortunate that we now have two RFCs that are so similar. Voting on them in isolation could result in an undesirable outcome.

Regards,

Sjoerd Langkemper

Request for RFC karma

Sun, 01 Nov 2026 11:13:42 +0000

Hi internals,

I'd like to request RFC karma for my PHP Wiki account.

Wiki username: artukrainskiy

I'm preparing an RFC for native multi-pattern string search and replacement
using Aho-Corasick, with two new classes: Str\Matcher and Str\Replacer.

I've opened a draft implementation PR:
https://github.com/php/php-src/pull/25122

Benchmarks and analysis are available here:
https://github.com/ArtUkrainskiy/php-src-bench/tree/main/reports/multi-pattern-search

I'd like to create a draft RFC to document the proposal and discuss the API
and design with the community.

--
Best regards,
Artem Ukrainskiy

RFC karma request: grapheme_str_pad()

Sat, 31 Oct 2026 23:42:27 +0000

Hi Chris

I'd like to request RFC karma on the wiki to propose a new function,
grapheme_str_pad(). My wiki username is: chrisabner

RFC karma was granted. Good luck!

Ilija

[VOTE] [RFC] Case-insensitive extension names in ini_get_all()

Fri, 30 Oct 2026 15:41:32 +0000

Hi all,

Nice to write you this email. This is an intent-to-vote email to
announce the "Case-insensitive extension names in ini_get_all()"
RFC will be voted two days later, which is 2 Nov.

RFC: https://wiki.php.net/rfc/case_insensitive_ini_get_all
RFC discussion thread: https://news-web.php.net/php.internals/132875
Initial discussion thread: https://externals.io/message/132226

I understand this may sounds like a very minor change to be vote
on. However, considering some objected the change, the only way
to implement this BC break is to go through a RFC process.

Thank you,
Weilin

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Fri, 30 Oct 2026 14:22:40 +0000

Hi Larry,

Sorry for the top post :/

We're still early in the process of Scope adoption, and Scope will
have to interact with existing worker modes anyway, because their APIs
are already widely used in the wild.

Scope will also have to deal with what my proposal solves: letting
extensions detect when the response has been sent (currently, a Scope
lives as long as something references it, which can be long after the
request is finished), and resetting the state tied to the request:
sessions (as explained in the Scope RFC), output buffers, the URL
rewriter, etc.

I propose combining the two: once Scope is accepted and implemented,
php_request_begin() will create a new scope, and SAPIs will get it for
free. When the HTTP response is finished, SAPIs call
php_request_end(), so extensions have a hook to do what they want when
a request terminates, even if the Scope survives because it is still
referenced.

For instance, with FrankenPHP:

&lt;?php
$scope = null;
while (frankenphp_handle_request(function () use (&$scope) {
    // C function php_request_begin() has been called by

FrankenPHP's SAPI: this callback runs in a new scope
$scope = Scope::getCurrent(); // leaked on purpose
})) {
// php_request_end() called by FrankenPHP: the session is
written and extensions flushed their data, even though $scope is still
alive
}

The user-space and engine-space lifetimes stay in sync because the
SAPI drives both.

Both proposals work well together. It also allows continuing work on
both (almost) independently and lets them ship at their own pace,
regardless of the result of their respective votes.

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Fri, 30 Oct 2026 13:42:23 +0000

After an off-list discussion with Tim Düsterhus, I'm retracting some
of the examples from my first email: http_get_last_response_headers(),
the libxml errors, error_get_last() and strtok(). They don't depend on
the incoming HTTP request, so a worker SAPI shouldn't reset them
between "logical" requests. Like any other state shared in worker
mode, userland can clear them when needed with the existing functions
(http_clear_last_response_headers(), libxml_clear_errors(),
error_clear_last()).

The rule I'm proposing is narrower: reset only the state built from
the incoming request or tied to its response. The session module and
output_add_rewrite_var() still fall under it.

The main point of the proposal stands: hooks for "logical" requests
give extensions one abstraction that works with every SAPI that has a
worker mode, instead of special-casing each one.

FrankenPHP will follow the same rule in its next release.

Tim suggested a short RFC. I'll write it soon.

Bottom post, please. :-)

I'm still a bit fuzzy on how this would interact with Scopes. Specifically, I presume we would want the user-space definition of "request lifetime" and the engine-space definition of "request lifetime" to be in sync. But as you note, Scopes as proposed don't have a clear and obvious The End that can correspond to firing the request end hook. So what would that coordination look like? Some contrived code samples would probably help.

--Larry Garfield

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Fri, 30 Oct 2026 12:51:03 +0000

After an off-list discussion with Tim Düsterhus, I'm retracting some
of the examples from my first email: http_get_last_response_headers(),
the libxml errors, error_get_last() and strtok(). They don't depend on
the incoming HTTP request, so a worker SAPI shouldn't reset them
between "logical" requests. Like any other state shared in worker
mode, userland can clear them when needed with the existing functions
(http_clear_last_response_headers(), libxml_clear_errors(),
error_clear_last()).

The rule I'm proposing is narrower: reset only the state built from
the incoming request or tied to its response. The session module and
output_add_rewrite_var() still fall under it.

The main point of the proposal stands: hooks for "logical" requests
give extensions one abstraction that works with every SAPI that has a
worker mode, instead of special-casing each one.

FrankenPHP will follow the same rule in its next release.

Tim suggested a short RFC. I'll write it soon.

Hello internals,

As you may know, FrankenPHP and some other SAPIs (like the
experimental ones written in Rust) have optional support for a "worker
mode". The main idea behind these worker modes is to use long-running
scripts, started when the web server starts, to handle multiple HTTP
requests in a loop.

This allows keeping states in memory across requests - such as the
Composer autoloader or Symfony and Laravel services - instead of
re-computing them at the beginning of each new request. This also
allows maintaining persistent connections to remote services across
requests.

Worker mode dramatically improves performance, at the cost of no
longer isolating state between requests and losing the memory leak
tolerance provided by the traditional "fire and forget" model. This
mode has become increasingly popular since the release of FrankenPHP,
and is now natively supported by a large part of the ecosystem
(Symfony, Laravel, Yii...).

Currently, the engine and extensions have no knowledge of this, and
have no way to detect when a "real" HTTP request starts or ends. As
expected, they are only aware of the start (and end) of the main,
long-running script. FrankenPHP (and other SAPIs with a similar mode)
reset "real HTTP request" related data by poking into the engine and
first-party extensions
(https://github.com/php/frankenphp/blob/7f50be9d86261bf7cff9b051ab4fb572e95020ed/frankenphp.c#L400-L646).
This approach is fragile, and the internal code resetting these states
can change without warning in a new PHP version.

Each omission results in a cross-request leak or a memory safety bug.
FrankenPHP fixed several of them this year:

a session ID leaking to other clients when ext/session is a shared
module, because FrankenPHP can only reset the session globals when it
is built against the session headers:
https://github.com/php/frankenphp/security/advisories/GHSA-v3ph-cgqh-r8p5

a use-after-free of php://temp streams, because nothing releases
SG(request_info).request_body between worker requests and FrankenPHP's
own cleanup freed streams it didn't own:
https://github.com/php/frankenphp/security/advisories/GHSA-cm3q-jw2q-9rh5

a double free because sapi_deactivate() frees
SG(request_info).content_type_dup and current_user without clearing
them (fixed for PHP 8.6: https://github.com/php/php-src/pull/22974):
https://github.com/php/frankenphp/security/advisories/GHSA-h764-4wh7-m7j2

http_get_last_response_headers() returning headers fetched by a
previous request:
https://github.com/php/frankenphp/security/advisories/GHSA-pmvg-8483-mw84

libxml_get_errors() returning errors of a previous request, with
parse-error fragments and server paths:
https://github.com/php/frankenphp/security/advisories/GHSA-4gfw-9v29-gp9h

Third-party extensions detect the boundaries themselves, each in its
own way. Xdebug and the Datadog profiler replace sapi_module.activate
and sapi_module.deactivate when the SAPI is FrankenPHP. Datadog's
tracer and AppSec, and New Relic in an open pull request, hook
frankenphp_handle_request(). Blackfire's Symfony bridge, Tideways and
Sentry wrap each request with start and stop calls in userland.

Calling RSHUTDOWN and RINIT between worker requests doesn't work:
these handlers mix state that needs resetting with state the script
keeps. For instance, the standard extension's RSHUTDOWN releases the
strtok() state, but also destroys register_tick_function() callbacks
and user stream filters. The session extension's RSHUTDOWN writes and
closes the session, but also frees the save handlers registered at
boot. The libxml extension's RSHUTDOWN drops the external entity
loader. Only each extension's maintainers know which of their globals
belong to which kind.

I'd like to add two optional module hooks, called by the SAPI between
two logical requests of the same script:

request_end: release the state tied to the finished request, but
keep everything still reachable from userland;

request_begin: set up the next request once its headers and
superglobals are available (session.auto_start, Xdebug's triggers).

Two engine functions, php_request_end() and php_request_begin(), would
run the output and SAPI steps that worker SAPIs copy today from
php_request_shutdown() and php_request_startup(), import the
superglobals of the new request (except $_ENV, which comes from the
process), set the execution timer, and call the hooks.

Releasing the request body takes two small changes: php://input
streams hold a reference to the body, and freeing the body, for
instance when the script closes it, clears
SG(request_info).request_body. Core extensions would implement the
hooks first; third-party extensions could adopt them at their pace.
SAPIs that don't call these functions see no behavior change.

I drafted a working patch for master, with the standard and session
hooks: https://github.com/dunglas/php-src/tree/request-boundary-hooks.
FrankenPHP doesn't build against master yet, so I tested it with a
patched version of FrankenPHP and it works.

As this is an internal API with no userland or BC impact, an RFC isn't
strictly needed.

I made a similar but broader proposal almost 3 years ago
(https://externals.io/message/122027). I think time has shown that
worker modes are here to stay, and this less intrusive proposal could
fix several maintenance issues affecting the whole ecosystem.

So, I would like your opinion on this before working more on it.

Best,

Kévin Dunglas

https://dunglas.dev

[RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

Fri, 30 Oct 2026 12:43:59 +0000

RFC link: https://wiki.php.net/rfc/password_bcrypt_wrap

Supports two prehash primitives, chosen through a prehash option: cshake256 (default) and sha512 (using HMAC construct).

PASSWORD_BCRYPT_WRAP supports two prehash algorithms. The prehash can be supplied in a hash option. Another possible solution is to create two password_hash algorithms, e.g. PASSWORD_BCRYPT_CSHAKE and PASSWORD_BCRYPT_SHA512.

Regards,

Sjoerd Langkemper

[RFC] Opt-in JSON Comments and Trailing Commas

Fri, 30 Oct 2026 12:22:58 +0000

Hi,

I intend to open the vote on this RFC on Monday, 2 November 2026, at
12:00 UTC. The vote will end on Monday, 16 November 2026, at 12:00 UTC.

There are two primary votes, one for each flag. Each vote needs a 2/3
majority.

Otar

Hello internals,

I want to start the discussion of the RFC "Opt-in JSON Comments and
Trailing Commas":
https://wiki.php.net/rfc/json_comments_trailing_commas

The RFC adds two independent opt-in flags for json_decode() and
json_validate():

JSON_ALLOW_COMMENTS accepts // line comments and /* block comments
*/.

JSON_ALLOW_TRAILING_COMMAS accepts one comma after the last item
of a
non-empty array or object.

Strict JSON stays the default. json_encode() does not change.

This RFC follows the pre-RFC thread:
https://news-web.php.net/php.internals/132236

Thank you for the feedback in that thread. The RFC now answers it:

The RFC does not add JSON5. It compares the two flags with JSON5,
JSONC and JWCC (Larry, Anton).

The RFC keeps two flags, not one JSON_ALLOW_JSONC flag. The JSONC
specification is a draft, and it makes trailing commas optional. The

section "Rejected Features" gives all reasons (Tim).

The RFC includes test results and performance measurements.

The implementation is here:
https://github.com/php/php-src/pull/23336

The RFC has two primary votes, one for each flag. Each vote needs a
2/3
majority.

All feedback is welcome.

Otar

I am forced to agree with Tim. This is a very tight RFC, and I have no
remaining objections to it. Nicely done!

--Larry Garfield

[RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

Fri, 30 Oct 2026 10:22:37 +0000

I'm happy to correct vagueness, especially if you can point to the unclear
piece of text. However, you are wrong on multiple counts here, and the
answer as to why is in those exact last words in the quote: domain
separation from naked hashes.
Not only is there domain separation from naked hashes, there's domain
separation between the Bcrypt and prehash salts (and even further than
that).

Perhaps it would be useful to add to the RFC a non-technical explanation of how hash shucking works, and how adding salt or pepper at the right stage protects against it.

I attempted to do that in the previous discussion here, based on my own limited understanding: https://externals.io/message/132784#132850

Regards,
Hi Andrey,

Thanks for the carefully designed RFC. It seems like a useful addition.

Rowan Tommins
[IMSoP]

GitHub access request

Fri, 30 Oct 2026 09:55:21 +0000

Hello,

I would like access to php-src in GitHub. I would like to merge my own approved pull requests, and review other people's pull requests. I have previously done some work on the curl extension and I think it would be a good idea to register myself as code owner for that extension, so that I can review merge requests related to curl.

There's a form to request access, but it gave an error since I already have a PHP account (sjoerd). My GitHub username is Sjord.

Regards,

Sjoerd Langkemper

[RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

Fri, 30 Oct 2026 08:36:23 +0000

I'd like to open the discussion on a new password hashing algorithm
that
I've been working on, named bcrypt-wrap.

RFC link: https://wiki.php.net/rfc/password_bcrypt_wrap
Pull request: https://github.com/php/php-src/pull/25040 (just pushed
it, CI
still running)

Thank you for the RFC and entertaining my questions in Discord. As
promised, I want to put the points onto the list for public record:

Can you please add a (pseudo) code description of your construction to
the RFC? Prose is needlessly ambiguous as also evidenced by Kamil’s
misunderstanding.
The section on “bcrypt-sha256” is very vague in how your construction
is better. Given that both bcrypt-sha256 and your bcrypt-wrap (with
SHA-512) use a HMAC construction using the (BCrypt) salt as a key as the
pre-hash, folks will rightfully wonder how the bcrypt-wrap construction
is better than that of bcrypt-sha256 (other than using a different hash
function) and should not be required to “reverse engineer” the
differences.

Best regards
Tim Düsterhus

[RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

Thu, 29 Oct 2026 23:29:14 +0000

Hi Kamil,

I'm rather against it. Your proposed implementation decreases security
of bcrypt implementation for small and dubious gains. The input space
is decreased from 2^576 to 2^432, which is a magnitude of 2^144. Sure,
these are astronomical values, but it's a significant decrease
nonetheless.

Sorry, but this is complete nonsense. A prehash doesn't reduce Bcrypt's
security or input space, and the "dubious gains" are masking all of
Bcrypt's limitations on inputs.

Additionally, your implementation suffers from hash shucking. OWASP

explicitly warns about doing it the way you are doing it:

Just using pure SHA-512, ( i.e. bcrypt(base64(sha512($password))),
$salt, $cost)) is a dangerous practice and is as secure as just using pure
SHA-512.

https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

That's not how I'm doing it. Not even close.

You mention HMAC, but it's a bit vague and looking at the
implementation, I believe you use the public salt as a secret key.
This may obfuscate the hash, but as I understand it, it does not make
pre-hashing safe. In fact the blog which I assume you have looked at
before (https://soatok.blog/2024/11/27/beyond-bcrypt/) describes the
problems in detail:

You can avoid hash shucking by using HMAC with a static key–either
universal for all deployments of your software, or unique per application.

It doesn’t really matter which you choose; all you really need from it is
domain separation from naked hashes.

I'm happy to correct vagueness, especially if you can point to the unclear
piece of text. However, you are wrong on multiple counts here, and the
answer as to why is in those exact last words in the quote: domain
separation from naked hashes.
Not only is there domain separation from naked hashes, there's domain
separation between the Bcrypt and prehash salts (and even further than
that).

And while I have indeed read Soatok's blog, the insinuation that it's the
basis of my work is both rude and false. I'd be more than familiar with
password shucking with or without it, which is why I can tell you what he
meant there by suggesting a static key: even a static key is good enough,
not only a static key.
The salt being used that way adds more strength (which some would call
overkill), not less. It being public has no effect on the purpose it serves
either.

So what do we gain instead? Your RFC does not clearly state the
benefits we gain at the cost of reduced security.

Perhaps it was foolish of me to think that listing Bcrypt's well-known
issues in the very first sentence of the RFC introduction is enough to
suggest that they'd be fixed. Maybe I could be more explicit about it, and
maybe you could not so aggressively strawman too. Just to be crystal clear:
there is no reduced security.

Cheers,
Andrey.

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Thu, 29 Oct 2026 22:53:03 +0000

Hi David,

Doesn't PHP with ZTS (Zend Thread Safety) offers the same capabilities?

No, it's a different thing. ZTS gives each thread its own copy of the
engine and extension globals, so several threads can run requests in
parallel in the same process. But in both models, RINIT and RSHUTDOWN
run once per script execution.

In worker mode, a thread runs one script that handles many requests in
a loop, so RINIT and RSHUTDOWN only run when that script starts and
ends. ZTS doesn't change that.  By the way, FrankenPHP always uses
ZTS, because it's written in Go, and Go relies heavily on threads
(goroutines rely on system threads under the hood).

Best

Hello Kévin,

I have a question. Doesn't PHP with ZTS (Zend Thread Safety) offers the same capabilities?

I remember I read something about it. What you described reminded me of it. Although as I'm not an expert in the area I can't tell.

The following link is from the PHP internal book for PHP lifecycle. (Although it says php7, I understand that it works the same for PHP8).
https://www.phpinternalsbook.com/php7/extensions_design/php_lifecycle.html

I sent a screenshot of the page in attachment.

I'm curious if this has to do with the question.

Kind regards,
David Maye

Hello internals,

As you may know, FrankenPHP and some other SAPIs (like the
experimental ones written in Rust) have optional support for a "worker
mode". The main idea behind these worker modes is to use long-running
scripts, started when the web server starts, to handle multiple HTTP
requests in a loop.

This allows keeping states in memory across requests - such as the
Composer autoloader or Symfony and Laravel services - instead of
re-computing them at the beginning of each new request. This also
allows maintaining persistent connections to remote services across
requests.

Worker mode dramatically improves performance, at the cost of no
longer isolating state between requests and losing the memory leak
tolerance provided by the traditional "fire and forget" model. This
mode has become increasingly popular since the release of FrankenPHP,
and is now natively supported by a large part of the ecosystem
(Symfony, Laravel, Yii...).

Currently, the engine and extensions have no knowledge of this, and
have no way to detect when a "real" HTTP request starts or ends. As
expected, they are only aware of the start (and end) of the main,
long-running script. FrankenPHP (and other SAPIs with a similar mode)
reset "real HTTP request" related data by poking into the engine and
first-party extensions
(https://github.com/php/frankenphp/blob/7f50be9d86261bf7cff9b051ab4fb572e95020ed/frankenphp.c#L400-L646).
This approach is fragile, and the internal code resetting these states
can change without warning in a new PHP version.

Each omission results in a cross-request leak or a memory safety bug.
FrankenPHP fixed several of them this year:

a session ID leaking to other clients when ext/session is a shared
module, because FrankenPHP can only reset the session globals when it
is built against the session headers:
https://github.com/php/frankenphp/security/advisories/GHSA-v3ph-cgqh-r8p5

a use-after-free of php://temp streams, because nothing releases
SG(request_info).request_body between worker requests and FrankenPHP's
own cleanup freed streams it didn't own:
https://github.com/php/frankenphp/security/advisories/GHSA-cm3q-jw2q-9rh5

a double free because sapi_deactivate() frees
SG(request_info).content_type_dup and current_user without clearing
them (fixed for PHP 8.6: https://github.com/php/php-src/pull/22974):
https://github.com/php/frankenphp/security/advisories/GHSA-h764-4wh7-m7j2

http_get_last_response_headers() returning headers fetched by a
previous request:
https://github.com/php/frankenphp/security/advisories/GHSA-pmvg-8483-mw84

libxml_get_errors() returning errors of a previous request, with
parse-error fragments and server paths:
https://github.com/php/frankenphp/security/advisories/GHSA-4gfw-9v29-gp9h

Third-party extensions detect the boundaries themselves, each in its
own way. Xdebug and the Datadog profiler replace sapi_module.activate
and sapi_module.deactivate when the SAPI is FrankenPHP. Datadog's
tracer and AppSec, and New Relic in an open pull request, hook
frankenphp_handle_request(). Blackfire's Symfony bridge, Tideways and
Sentry wrap each request with start and stop calls in userland.

Calling RSHUTDOWN and RINIT between worker requests doesn't work:
these handlers mix state that needs resetting with state the script
keeps. For instance, the standard extension's RSHUTDOWN releases the
strtok() state, but also destroys register_tick_function() callbacks
and user stream filters. The session extension's RSHUTDOWN writes and
closes the session, but also frees the save handlers registered at
boot. The libxml extension's RSHUTDOWN drops the external entity
loader. Only each extension's maintainers know which of their globals
belong to which kind.

I'd like to add two optional module hooks, called by the SAPI between
two logical requests of the same script:

request_end: release the state tied to the finished request, but
keep everything still reachable from userland;

request_begin: set up the next request once its headers and
superglobals are available (session.auto_start, Xdebug's triggers).

Two engine functions, php_request_end() and php_request_begin(), would
run the output and SAPI steps that worker SAPIs copy today from
php_request_shutdown() and php_request_startup(), import the
superglobals of the new request (except $_ENV, which comes from the
process), set the execution timer, and call the hooks.

Releasing the request body takes two small changes: php://input
streams hold a reference to the body, and freeing the body, for
instance when the script closes it, clears
SG(request_info).request_body. Core extensions would implement the
hooks first; third-party extensions could adopt them at their pace.
SAPIs that don't call these functions see no behavior change.

I drafted a working patch for master, with the standard and session
hooks: https://github.com/dunglas/php-src/tree/request-boundary-hooks.
FrankenPHP doesn't build against master yet, so I tested it with a
patched version of FrankenPHP and it works.

As this is an internal API with no userland or BC impact, an RFC isn't
strictly needed.

I made a similar but broader proposal almost 3 years ago
(https://externals.io/message/122027). I think time has shown that
worker modes are here to stay, and this less intrusive proposal could
fix several maintenance issues affecting the whole ecosystem.

So, I would like your opinion on this before working more on it.

Best,

Kévin Dunglas

https://dunglas.dev

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Thu, 29 Oct 2026 22:52:40 +0000

Hello Pierre,

but shouldn't the need be covered by the Scope RFC https://wiki.php.net/rfc/scope

Not really, they solve different problems.

The Scope RFC gives an identity to requests running concurrently in
the same process. It doesn't provide a point where a request ends: as
the RFC says, a scope doesn't finish when run() returns. It also only
covers the superglobals, the session, the default locale and the
default timezone.

My proposal is a small internal refactoring that adds two optional
hooks, called between two requests served one after the other by the
same script. They let each extension release its own request state,
which today worker SAPIs reset by poking into the extensions' globals.
The bugs we fixed in FrankenPHP were in state the Scope RFC doesn't
cover: strtok(), the last HTTP response headers, libxml errors, the
request body.

It's a quality of life improvement for the existing ecosystem (SAPIs
with a worker mode and the extensions supporting them). Unlike the
Scope RFC, it has no impact on userland code and requires no change to
it. Worker modes are already widely used and will remain even if the
Scope RFC passes, at least for backward compatibility.

The two proposals are complementary. If both are accepted, the parts
touching the superglobals and the session would need to work together,
but nothing conflicts.

Best

Le 29/10/2026 à 18:47, Kévin Dunglas a écrit :

Hello internals,

Hello,

I see the point and I feel it's indeed at some point becomes a
requirement for long running servers, yet to be honest this not my area
of expertise, but shouldn't the need be covered by the Scope RFC
https://wiki.php.net/rfc/scope ?

The chosen path is different, but the goal seems to be the same in the end.

Regards,

Pierre

RFC karma request: grapheme_str_pad()

Thu, 29 Oct 2026 22:00:35 +0000

Hi internals,

I'd like to request RFC karma on the wiki to propose a new function,
grapheme_str_pad(). My wiki username is: chrisabner

It is the grapheme cluster counterpart of str_pad() and mb_str_pad(), as
suggested in the Future Scope of the mb_str_pad RFC [1]. The length is
counted in grapheme clusters, like grapheme_strlen() does:

grapheme_str_pad(string $string, int $length, string $pad_string = " ",
                 int $pad_type = STR_PAD_RIGHT): string|false

mb_str_pad() counts code points, so the same visible text gets different
padding depending on how it is encoded, and the padding string can be cut
inside a grapheme cluster:

mb_str_pad("Caf\u{00E9}", 6, '.');           // "Café.."
mb_str_pad("Cafe\u{0301}", 6, '.');          // "Café."  (NFD: one dot less)
mb_str_pad("a", 4, "u\u{0308}o\u{0308}");    // "aüo"    (ö lost its diaeresis)

grapheme_str_pad("Cafe\u{0301}", 6, '.');       // "Café.."
grapheme_str_pad("a", 4, "u\u{0308}o\u{0308}"); // "aüöü"

Errors and edge cases follow mb_str_pad(); invalid UTF-8 returns false like grapheme_strlen(). I have an implementation with tests in ext/intl and will
open a pull request together with the RFC.

I'll open the formal [RFC] discussion thread once the wiki page is up.

[1] https://wiki.php.net/rfc/mb_str_pad#future_scope

Thanks,
Chris Abner Herrera Navarro

[Meta] This Week In PHP Internals | October 29, 2026

Thu, 29 Oct 2026 21:54:33 +0000

Hi Contributors,

This week's episode is out. Here's the video, plus everywhere else it landed
for visibility.

Same invitation as always: if I got something wrong, reply in this thread
and
I'll make corrections. That includes how I'm pronouncing your names.

If you'd rather read than watch, the dev.to post carries the full episode as
an article, which also makes it the easiest version to quote when correcting
me: https://dev.to/projektgopher/this-week-in-php-internals-oct-29-2026-1m75

youtube https://youtu.be/oeDHs-qXXwA
r/php
https://www.reddit.com/r/PHP/comments/1xix3qk/this_week_in_php_internals_oct_29_2026/
r/symfony
https://www.reddit.com/r/symfony/comments/1xix6f5/this_week_in_php_internals_oct_29_2026/
r/laravel
https://www.reddit.com/r/laravel/comments/1xix9qe/this_week_in_php_internals_oct_29_2026/
dev.to
https://dev.to/projektgopher/this-week-in-php-internals-oct-29-2026-1m75
mastodon https://phpc.social/@ProjektGopher/117526253139268972
threads https://www.threads.com/@projektgopher/post/DfF9VKxkl-6
bsky https://bsky.app/profile/projektgopher.com/post/3mz27x74cwy2w
twitter https://x.com/ProjektGopher/status/2115915517009801479
linkedin
https://www.linkedin.com/feed/update/urn:li:activity:7521683881872371713/
pinkary
https://pinkary.com/@ProjektGopher/questions/01a1898e-f67e-72f1-a20f-7e074590a55c

Cheers,
Len

[RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

Thu, 29 Oct 2026 21:39:47 +0000

Hi all,

I'd like to open the discussion on a new password hashing algorithm that I've been working on, named bcrypt-wrap.

RFC link: https://wiki.php.net/rfc/password_bcrypt_wrap
Pull request: https://github.com/php/php-src/pull/25040 (just pushed it, CI still running)

P.S. Thanks to Sjoerd for honoring my request to delay his bcrypt-sha256 proposal while I finished this.

Cheers,
Andrey.

Hi Andrey,

I'm rather against it. Your proposed implementation decreases security
of bcrypt implementation for small and dubious gains. The input space
is decreased from 2^576 to 2^432, which is a magnitude of 2^144. Sure,
these are astronomical values, but it's a significant decrease
nonetheless.

Additionally, your implementation suffers from hash shucking. OWASP
explicitly warns about doing it the way you are doing it:

Just using pure SHA-512, ( i.e. bcrypt(base64(sha512($password))), $salt, $cost)) is a dangerous practice and is as secure as just using pure SHA-512.
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

You mention HMAC, but it's a bit vague and looking at the
implementation, I believe you use the public salt as a secret key.
This may obfuscate the hash, but as I understand it, it does not make
pre-hashing safe. In fact the blog which I assume you have looked at
before (https://soatok.blog/2024/11/27/beyond-bcrypt/) describes the
problems in detail:

You can avoid hash shucking by using HMAC with a static key–either universal for all deployments of your software, or unique per application.

It doesn’t really matter which you choose; all you really need from it is domain separation from naked hashes.

So what do we gain instead? Your RFC does not clearly state the
benefits we gain at the cost of reduced security.

Regards,
Kamil Tekiela

[RFC] openssl_get_channel_binding

Thu, 29 Oct 2026 20:18:51 +0000

Thank you for the thorough review.

Hi

I have created an RFC to add the function openssl_get_channel_binding:
https://wiki.php.net/rfc/openssl_get_channel_binding

“The function returns null when the requested type is not applicable
to the connection.”

An operation that is not applicable sounds like an Exception to me. Is
there currently any other situation where null is returned?

No. I can see the appeal of throwing a specific exception (e.g. UnsupportedChannelBinding extends OpensslExtension). Then if the function returns something the caller knows it is a valid channel binding value.

The RFC already identifies the case for tls-unique over TLS 1.3. I think using tls-server-end-point over TLS-PSK also may not work (because there's no certificate) and should also throw such an exception.

“$stream is a stream, but it has no active OpenSSL TLS transport”

That sounds like a programmer error, thus Openssl\OpensslError (or
potentially ValueError).

Yes, I agree.

“An OpenSSL call fails while computing the value”

Is this one reachable in practice or is this more of a generic “catch
all” error that cannot really happen?

This was meant as a generic catch all for things that should not normally fail.

“Because the second parameter is an enum, the function itself no
longer has an unknown-type error. […]”

This paragraph should probably not be mentioned in the RFC

Yes, I agree. I removed this.

RFC Impact to “To Existing Extensions”

Are there perhaps any extensions that might want to make use of the new
functionality internally? For example pdo_pgsql, I'm noting that the RFC
mentions tests against PostgreSQL?

I hadn't considered this. Not really. Most extensions don't use a connection managed by ext/openssl. E.g. for postgres, libpq does the TLS handling and also the channel binding. Mysqlnd does use a PHP stream, but MySQL/mariadb don't have any channel binding functionality.

Regards,

Sjoerd Langkemper

[RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

Thu, 29 Oct 2026 20:06:42 +0000

Hi all,

I'd like to open the discussion on a new password hashing algorithm that
I've been working on, named bcrypt-wrap.

RFC link: https://wiki.php.net/rfc/password_bcrypt_wrap
Pull request: https://github.com/php/php-src/pull/25040 (just pushed it, CI
still running)

P.S. Thanks to Sjoerd for honoring my request to delay his bcrypt-sha256
proposal while I finished this.

Cheers,
Andrey.

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Thu, 29 Oct 2026 18:20:51 +0000

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Thu, 29 Oct 2026 18:01:57 +0000

Le 29/10/2026 à 18:47, Kévin Dunglas a écrit :

Hello internals,

Hello,

I see the point and I feel it's indeed at some point becomes a
requirement for long running servers, yet to be honest this not my area
of expertise, but shouldn't the need be covered by the Scope RFC
https://wiki.php.net/rfc/scope ?

The chosen path is different, but the goal seems to be the same in the end.

Regards,

Pierre

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Thu, 29 Oct 2026 17:47:58 +0000

Hello internals,

As you may know, FrankenPHP and some other SAPIs (like the
experimental ones written in Rust) have optional support for a "worker
mode". The main idea behind these worker modes is to use long-running
scripts, started when the web server starts, to handle multiple HTTP
requests in a loop.

This allows keeping states in memory across requests - such as the
Composer autoloader or Symfony and Laravel services - instead of
re-computing them at the beginning of each new request. This also
allows maintaining persistent connections to remote services across
requests.

Worker mode dramatically improves performance, at the cost of no
longer isolating state between requests and losing the memory leak
tolerance provided by the traditional "fire and forget" model. This
mode has become increasingly popular since the release of FrankenPHP,
and is now natively supported by a large part of the ecosystem
(Symfony, Laravel, Yii...).

Currently, the engine and extensions have no knowledge of this, and
have no way to detect when a "real" HTTP request starts or ends. As
expected, they are only aware of the start (and end) of the main,
long-running script. FrankenPHP (and other SAPIs with a similar mode)
reset "real HTTP request" related data by poking into the engine and
first-party extensions
(https://github.com/php/frankenphp/blob/7f50be9d86261bf7cff9b051ab4fb572e95020ed/frankenphp.c#L400-L646).
This approach is fragile, and the internal code resetting these states
can change without warning in a new PHP version.

Each omission results in a cross-request leak or a memory safety bug.
FrankenPHP fixed several of them this year:

a session ID leaking to other clients when ext/session is a shared
module, because FrankenPHP can only reset the session globals when it
is built against the session headers:
https://github.com/php/frankenphp/security/advisories/GHSA-v3ph-cgqh-r8p5
a use-after-free of php://temp streams, because nothing releases
SG(request_info).request_body between worker requests and FrankenPHP's
own cleanup freed streams it didn't own:
https://github.com/php/frankenphp/security/advisories/GHSA-cm3q-jw2q-9rh5
a double free because sapi_deactivate() frees
SG(request_info).content_type_dup and current_user without clearing
them (fixed for PHP 8.6: https://github.com/php/php-src/pull/22974):
https://github.com/php/frankenphp/security/advisories/GHSA-h764-4wh7-m7j2
http_get_last_response_headers() returning headers fetched by a
previous request:
https://github.com/php/frankenphp/security/advisories/GHSA-pmvg-8483-mw84
libxml_get_errors() returning errors of a previous request, with
parse-error fragments and server paths:
https://github.com/php/frankenphp/security/advisories/GHSA-4gfw-9v29-gp9h

Third-party extensions detect the boundaries themselves, each in its
own way. Xdebug and the Datadog profiler replace sapi_module.activate
and sapi_module.deactivate when the SAPI is FrankenPHP. Datadog's
tracer and AppSec, and New Relic in an open pull request, hook
frankenphp_handle_request(). Blackfire's Symfony bridge, Tideways and
Sentry wrap each request with start and stop calls in userland.

Calling RSHUTDOWN and RINIT between worker requests doesn't work:
these handlers mix state that needs resetting with state the script
keeps. For instance, the standard extension's RSHUTDOWN releases the
strtok() state, but also destroys register_tick_function() callbacks
and user stream filters. The session extension's RSHUTDOWN writes and
closes the session, but also frees the save handlers registered at
boot. The libxml extension's RSHUTDOWN drops the external entity
loader. Only each extension's maintainers know which of their globals
belong to which kind.

I'd like to add two optional module hooks, called by the SAPI between
two logical requests of the same script:

request_end: release the state tied to the finished request, but
keep everything still reachable from userland;
request_begin: set up the next request once its headers and
superglobals are available (session.auto_start, Xdebug's triggers).

Two engine functions, php_request_end() and php_request_begin(), would
run the output and SAPI steps that worker SAPIs copy today from
php_request_shutdown() and php_request_startup(), import the
superglobals of the new request (except $_ENV, which comes from the
process), set the execution timer, and call the hooks.

Releasing the request body takes two small changes: php://input
streams hold a reference to the body, and freeing the body, for
instance when the script closes it, clears
SG(request_info).request_body. Core extensions would implement the
hooks first; third-party extensions could adopt them at their pace.
SAPIs that don't call these functions see no behavior change.

I drafted a working patch for master, with the standard and session
hooks: https://github.com/dunglas/php-src/tree/request-boundary-hooks.
FrankenPHP doesn't build against master yet, so I tested it with a
patched version of FrankenPHP and it works.

As this is an internal API with no userland or BC impact, an RFC isn't
strictly needed.

I made a similar but broader proposal almost 3 years ago
(https://externals.io/message/122027). I think time has shown that
worker modes are here to stay, and this less intrusive proposal could
fix several maintenance issues affecting the whole ecosystem.

So, I would like your opinion on this before working more on it.

Best,

Kévin Dunglas

https://dunglas.dev

[RFC] CSV Extension (ext/csv)

Thu, 29 Oct 2026 16:27:01 +0000

Hi

Does it mean that the LazyLaxCollection will expose the stream metadata
?
If I receive in my method/function a LazyLaxCollection is it possible
for
me to get access to the underlying resource metadata ? To know how it
is
open, its pathname , and so forth ? Can I easily detect if

That paragraph appears to be cut off. Can you check?

Best regards
Tim Düsterhus

Indeed it was cut off I rephrased it as follow:

Does this mean that LazyLaxCollection will expose the stream metadata?

If I receive a LazyLaxCollection instance in a method or function, will I
be able to access the underlying resource metadata:

understand how the stream was opened,
retrieve its pathname, and ... ?
can I easily determine whether the underlying stream is a local file,
a temporary file, a memory stream, or something else?

These are genuine questions that someone might ask when working with an
instantiated LazyLaxCollection object.

[RFC] CSV Extension (ext/csv)

Thu, 29 Oct 2026 16:16:11 +0000

Does it mean that the LazyLaxCollection will expose the stream metadata
?
If I receive in my method/function a LazyLaxCollection is it possible
for
me to get access to the underlying resource metadata ? To know how it
is
open, its pathname , and so forth ? Can I easily detect if

That paragraph appears to be cut off. Can you check?

Best regards
Tim Düsterhus

[RFC] CSV Extension (ext/csv)

Thu, 29 Oct 2026 15:33:42 +0000

On Fri, Oct 9, 2026 at 8:22 AM Damian Jóźwiak damian.jozwiak.lodz@gmail.com
wrote:

Hi internals,

I'd like to open the discussion on an RFC proposing a dedicated CSV
extension (ext/csv) for PHP core.

RFC: https://wiki.php.net/rfc/csv_extension

Implementation: https://github.com/php/php-src/pull/24199

The proposal builds upon Gina Peter Banyard's girgias/csv extension
(BSD-3-Clause), with additional functionality for file and stream handling.

The motivation includes the deprecation of the SplFileObject CSV methods
in PHP 8.6, which leaves certain use cases without a direct replacement.

The proposed extension provides:

Six functions and one class in the Csv\ namespace.

RFC 4180-compatible parsing and serialization by default.

Locale-independent processing without the proprietary escape mechanism.

Multibyte delimiters, enclosures, and EOL sequences.

Strict and lax collection parsing.

Lazy iteration over CSV files and streaming output.

The implementation includes PHPT tests covering parsing, serialization,
stream handling, resource lifetime, and various edge cases.

The pull request's CI checks are currently passing across the tested
platforms, including debug, ZTS, and AddressSanitizer configurations.

The initial API is deliberately kept small. A more comprehensive
object-oriented Reader/Writer API, including capability-oriented
interfaces, is left for potential future discussion.

I'd particularly appreciate feedback on the public API design, the naming
of LazyLaxCollection, and whether the extension should be always enabled
or optional at build time.

For transparency, Gina has not reviewed or endorsed this RFC. Parts of the
implementation were developed with LLM assistance; I have reviewed the code
and take full responsibility for the contribution.

This is an invitation for discussion, not a call for votes.

Thanks in advance for your feedback.

Best regards,
Damian Jóźwiak

Hi Damien,
thanks for the proposal, indeed with the deprecation of SplFileObject CSV
feature an object oriented alternative is welcomed having said that.I have
a couple of remarks/suggestions

Following Tim's thought, I wonder if a CSV top namespace is mandatory
or if we should not just have a Serialization "namespace" name that can be
improved when such classes and functions are defined.

RFC 4180-compatible parsing and serialization by default. As much as I
am a proponent of backing RFC whenever they exist in this case it should be
stressed out that RFC4180 is not an accepted RFC like for instance RFC3986
for URI specification as such it is totally possible to have a valid CSV
which does not comply with the refer draft specification. I believe this
should be noted and explained in the RFC to avoid pushing forward something
which is not a real specification as anyone would expect even though it is
widely accepted as the "default" implementation,

Hence why I believe that using terms like lax and strict is counter
productive; probably other names "to be defined" should be used instead.
Maybe adding an Enum With RFC4180 and something else (?) would be a better
take. Which would reduce the number of function/methods introduced ?

Also while it is common to talk about CSV, this feature would be
perhaps better called Character Separated Value than Comma Separated
Value since the delimiter can be changed. And covers TSV and other exotic
formats which separates values per single character.

The stream is owned by the object: like the stream of SplFileObject, it

remains visible as a resource but fclose() refuses to close it, and it is
closed when the object is destroyed (for an object alive until the end of
the request, while destructors run, so a user wrapper's stream_close() is
still called).

Does it mean that the LazyLaxCollection will expose the stream metadata ?
If I receive in my method/function a LazyLaxCollection is it possible for
me to get access to the underlying resource metadata ? To know how it is
open, its pathname , and so forth ? Can I easily detect if

Being able to configure the context or to apply stream filter is also
something I find useful with the current set of csv function even with
SplFileObject (even though it is tricky with that one) I would expect any
API which aim at replacing the current CSV API to offer at most the same
extensibility or to allow it in any other shape or form.

function collection_to_file(string $file, iterable $collection, string
$delimiter = ',', string $enclosure = '"', string $eolSequence =
"\r\n"): void {}

Why? can't we have access to the written bytes as returned value. Otherwise
it means we need to re-access the resource afterward if we want to get
access to that value. For example if we want to generate the Content-Length
header or something else ?

Overall, I like the direction of the RFC but I believe some major
discussion points remain unsolved before going to a vote

Best regards,
Ignace

PHP 8.4.27 configure writes to read-only source tree but exits successfully

Thu, 29 Oct 2026 15:05:57 +0000

I found a reproducible out-of-tree build-system issue in the signed PHP
8.4.27 release. I am using the internals list because bugs.php.net no
longer accepts reports and GitHub is unavailable in this environment.

Thank you for your report. A PR was filed by Pratik in response to your
email: https://github.com/php/php-src/pull/24597.

Best regards
Tim Düsterhus

SSRF protection in curl

Thu, 29 Oct 2026 14:05:49 +0000

Hi Levi,

Good point, with one caveat. I think we might apply the same logic to
streams, but as the decision must be made per-request, the implementation
should be specific per api.
So I'd rather focus on curl here and make sure it lands in 8.7, then we
might open another rfc for streams.

WDYT ?

Le jeu. 22 oct. 2026 à 16:58, Levi Morrison levi.morrison@datadoghq.com a
écrit :

Is there any reason we should intentionally make this curl specific?
Meaning, we could design support for making it work for streams as
well, couldn't we? Why make a curl specific feature instead of a
language wide one?

[RFC] Time\Instant and Time\Clock

Thu, 29 Oct 2026 13:57:00 +0000

get vs to

I agree with this. $foo->toBar() is a very common "type conversion"
pattern, and it makes sense to use here as well.

Already adjusted a while ago.

getUnixTimestamp() / getUnixTimestampMilliseconds()

I would agree here as well.

See the reply I just sent to Marc.

A dedicated parser/formatter instead

I'd prefer parsing and formatting to live in a dedicated
parser/formatter
API (future scope) rather than on Instant, where it would sit next to
the
other ISO-8601 profiles and custom patterns. If the pair stays on
Instant,
the name should say what it really is (a fixed RFC 3339-like profile),
and
the grammar should be part of what we vote on.

I understand the tidiness/purity argument here, and I am generally
sympathetic to it. However, that always needs to be balanced against
usability. Any incoming date/time information to the PHP process is
likely to be either an ISO-8601 string or a unix timestamp int. If we
want people to convert those into Instants for doing manipulation and
comparison on (which I presume is the case), then that needs to be
ergonomically easy to do. Having to go through multiple
parser/converter objects (which some purist is likely to insist be
injected from a container rather than instantiated directly; I have
been known to be that purist) to get there is not ergonomic. So if
that logic is split off, we would need to be very careful to ensure the
result is ergonomically simple and readily copy-pasteable.

Yes, I've expanded a little more in my own words in the reply I just
sent to Marc.

Regarding the “purist note”: Injecting a formatter (into your template
engine) actually is reasonable. The correct choice there would likely be
one backed by ext/intl.

And of course, as I had noted in
https://news-web.php.net/php.internals/132608 and the reply to Marc,
arbitrary formatting is only well-defined for a ZonedDateTime (or
PlainDateTime - naming tbd - when the timezone is implied). For
Instant we can just use anything that unambiguously represents a point
in time, which basically boils down to ISO-8601 date time with zone
offset. Users are able to build their own parsers if they have a
requirement for special formats. Or parse into ZonedDateTime and
extract the instant via ZonedDateTime::$instant (or whatever it may be
called).

until() vs Duration::between()

Was Duration::between(Instant $a, Instant $b) considered? Calculating
a
duration feels like Duration's responsibility to me.

This also seems reasonable, as a named constructor of Duration.

See the reply I just sent to Marc.

Best regards
Tim Düsterhus

[RFC] Time\Instant and Time\Clock

Thu, 29 Oct 2026 13:39:14 +0000

Due to the security releases it's been a while since I last looked into
this RFC and I probably lost some of my working memory. Please indicate
if there is something obvious that I missed somewhere or similar.

Naming of Clock::now()

The method returns an Instant, but the RFC already plans future classes
that combine an instant with a timezone (a ZonedDateTime-like class).
Callers
will want to get those from a clock directly as well, without going the
long way around: $clock->now()->toZonedDateTime($zone). Once a clock
can return more than one type, now() no longer says what you get.

A “point in time” is the canonical representation of “now” for the
reasons that are also given in the RFC and this is also the type I
expect to be returned, even without including it in the name. As you
note yourself, a ZonedDateTime requires supplementary information (the
timezone) to be provided at call time. For that I would also not call it
“going the long way around”. As a direct comparison:

 $clock->now()->toZonedDateTime($zone)
 // vs your suggested
 $clock->takeZonedDateTime($zone)

saves a grand total of 5 characters, at the expense of making the “point
in time” retrieval much more verbose. The ZonedDateTime will very
likely be a thin wrapper over Instant + Timezone, thus the Instant
object can just be reused as ZonedDateTime::$instant.

I would also say that using a ZonedDateTime as the default type for
handling time is doing it wrong. The timezone is a presentation-layer
concern and stuff you “present” to the user is generally expected to be
coming from the database, rather than coming from the clock. Allowing
comparisons between ZonedDateTime and “now” can be enabled by just
making ZonedDateTime::compare() accept Instant|ZonedDateTime as the
parameters. The nice part of the compare() method is that it's
specifically designed for ordering rather than equality, thus a return
value of 0 can mean “same point in time” even if the timezones differ.

One constraint thought, PHP interfaces can't have default
implementations. Adding methods to Time\Clock later would break every
userland clock. So either the interface should get its full shape now,
or further result types should come in through factories on the target
types
(see 2).

Yes, adding methods to interfaces after the fact is a breaking change
and “huge interfaces” are an indicator of wrong design. Java solves this
by making the Clock an abstract class, but this also is a heavy-weight
solution to something that is not really a problem as per the above, so
…

Instant::fromClock(Clock $clock)

You rejected Instant::now() because it would tie Instant to the
SystemClock. With a required Clock parameter that objection goes away.
It is exactly what Java does. Later classes can then follow the same
pattern
(ZonedDateTime::fromClock($clock, $zone)) without the Clock interface
ever
growing.

… that would be a reasonable middle-ground of providing convenience
constructors. With the from*() prefix the naming is consistent and it
doesn't magically invent information out of thin air. Given that it's
pretty much redundant with $clock->now() with the current scope of the
RFC, I would punt this to when ZonedDateTime is introduced so that it
can be designed consistently across all classes.

Clock resolution

The docblock says "at the resolution offered by the underlying clock",
but
nothing in the API exposes that resolution (Rob raised the same point).
I
measured what the platforms report via clock_getres() and what they
actually deliver:

As I noted in my reply to Rob, I don't believe this is something that
belongs on the interface, since this information is unlikely to be
actionable by a majority of applications …

                         clock_getres()   smallest observed step
macOS arm64, REALTIME 1 us 1 us
Linux arm64, REALTIME 1 ns 42 ns (24 MHz counter)
Linux, REALTIME_COARSE 1 ms -

So clock_getres() is honest on some systems and only nominal on others.
I'd still like SystemClock to expose it, documented as the nominal
resolution of the source. That is better than no information at all.

… but we can see how exposing the (nominal) resolution of specifically
the SystemClock can be useful. I assume that a
SystemClock::getNominalResolution(): Duration with the Duration
being the greatest common divisor of possible returned values is what
you would expect? I have just added a future scope note to the RFC,
since I would need to do additional research into all the operating
systems supported by PHP. It's probably also something that can just go
in by “simple PR” without going through a full RFC, since this is a
minor feature on a final class.

Configurable clock resolution

Handled previously.

Taking a Unix timestamp directly from a clock

Unix timestamps are used everywhere, not only in PHP, so "current time
as a Unix timestamp" is a very common operation. Today that's time(),
which can't be mocked. With this RFC the mockable replacement is
$clock->now()->getUnixTimestamp(), which always goes through an Instant
object. I'd like a way to take the Unix timestamp directly from the
clock.

Our goal with this RFC series is to provide a well-designed and
well-typed new API that nudges the user to do the right thing. Making
“raw integers” a first class citizen would go against that goal to save
7 characters (and one object creation). The previous arguments against
adding a takeZonedDateTime() or similar also apply here.

"Follows POSIX time" vs. "unspecified representation"

The RFC states that Instants "follow POSIX time". At the same time it
says
that "the internal representation of Time\Instant is intentionally left
unspecified and there are deliberately no public properties. In
particular
the 'Unix timestamp' is not the primary representation."

I think an unspecified internal representation is the right way
forward. But it doesn't match the class being specified as POSIX time.
POSIX time is not just one of many ways to look at an instant. It is a
specific time
scale: seconds counted since 1970-01-01T00:00:00Z. If Instant follows
POSIX time, then the Unix timestamp (plus a fraction of a second) is
effectively the model of the class.

It's not quite seconds counted since 1970-01-01T00:00:00Z, the relevant
part is that leap seconds are dropped (which makes the POSIX timescale
different from UTC).

So I'd suggest not defining Instant itself in terms of POSIX time.
POSIX
time is relevant where Unix timestamps come in or go out, so it belongs
in
the documentation of the Unix timestamp constructor and getter, not in
the
definition of the class.

I'll look into cleaning up the wording when handling the points that Rob
mentioned.

get vs to

Handled previously.

getUnixTimestamp() / getUnixTimestampMilliseconds()

Only the milliseconds variant names its unit, and microseconds (used
all
over PHP: microtime(), DateTime) and nanoseconds are missing entirely.
A
single pair taking the unit as an argument would cover all of them and
stay symmetric:

The toUnixTimestamp() + getNanoseconds() pair is the canonical
representation of a Unix timestamp - with “seconds” also being arguably
by far the most common interpretation when hearing “Unix timestamp”. The
“milliseconds” variant is provided for interoperability convenience, in
particular with JavaScript.

PHP’s existing DateTime does not provide functionality to obtain the
timestamp as an integral number of microseconds, and microtime()
either returns a float or a weird two-component pair as a string. I am
not aware of anything commonly used that returns “integral microseconds
since the Unix epoch”, do you know of anything?

public static function fromUnixTimestamp(int $timestamp, TimeUnit
$unit = TimeUnit::Second): self;
public function toUnixTimestamp(TimeUnit $unit = TimeUnit::Second):
int;

TimeUnit would be an enum of Second, Millisecond, Microsecond and
Nanosecond, rounding towards negative infinity as already specified.
The

I do not find it obvious at all that “seconds” would be the largest
supported unit of a TimeUnit.

getNanoseconds()

Handled previously.

Concepts the ISO-8601 pair brings into Instant

An Instant is described as a timezone-less point in time. The ISO-8601
constructor and getter bring in several concepts that Instant otherwise
deliberately avoids:

a) parsing and formatting of date-time strings;
b) UTC as the reference ("Z" means a zero offset from UTC; since RFC
9557 it formally means "UTC known, local offset unknown");
c) a calendar: ISO 8601 uses the proleptic Gregorian calendar with
year
0000;
d) an opinionated input and output format

Yes. I don't understand what you are getting at, though. There clearly
has to be a way to represent a point in time in some way - and an
ISO-8601 datetime string is one of the possible options, probably the
most widely used one. The Unix timestamp is another one.

The accepted input grammar

The RFC says the parser is strict but "may not support all legal
formats",
and that accepted formats can be extended "by a simple pull request".
That
means the vote doesn't decide the accepted grammar. Widening it later
is
also not BC-neutral for code that uses the parser as a validator. I'd
like

Since the RFC guarantees that only legal formats will be accepted, you
are able to use it as a validator. If your use case requires narrower
validation, then you will need to perform custom validation according to
whatever specification you are dealing with. This is not unique to the
Instant class.

the RFC to specify the grammar explicitly and to state the outcome for
the
cases Ilia listed: comma decimal sign, lowercase t/z, space separator,
-00:00, 24:00:00, 23:59:60, more than 9 fractional digits.

See my reply to Ilia (https://news-web.php.net/php.internals/132764).
The RFC changes are still open.

A related point:
the docblock requires "a zone offset" while the prose requires "a
timezone". Is an RFC 9557 suffix such as [Europe/Berlin] accepted,
rejected or ignored?

Thanks, I adjusted the prose to also require a “zone offset”.

The output format

The getter always emits Z, has a fractional part whose width depends on
the value (omitted when zero, otherwise 9 digits), and uses signed
expanded years outside 0000-9999.

You mentioned that the getter implements the RFC 3339 subset of
ISO-8601.
That is not quite true: RFC 3339 only allows 4-digit years 0000-9999,
so the output isn't RFC 3339 for expanded years.

That is a bit of a distinction without difference: RFC 3339 is only
capable of representing years 0000 to 9999, so years outside of that
range are by definition not representable as RFC 3339. The ISO-8601
getter specifically only switches to the expanded format outside that
range. Adding a separate RFC 3339 getter that differs only by throwing
an Exception for unrepresentable instants does not sound useful, since
this Exception is not actionable in any way.

I also tested how well the possible outputs work as input for the
existing
DateTime API (PHP 8.5):

new DateTimeImmutable($s) accepts all of them, but truncates the 9
fractional digits to 6 without notice.

With createFromFormat() no single format string works. DATE_ATOM
only
matches whole seconds with 4-digit years. DATE_RFC3339_EXTENDED
(.v,
3 digits) never matches. 'Y-m-d\TH:i:s.uP' fails on 9 digits
because
'u' takes at most 6, so you need a hack like 'Y-m-d\TH:i:s.u???P'.
Expanded years need 'X' instead of 'Y'.

Because the fractional part is only present for some values, any strict
consumer needs at least two format strings and has to choose between
them,
which is the trap Ilia described. An output that always includes the
fractional part would at least make 'X-m-d\TH:i:s.u???P' work for every
value.

I do not believe that the existing DateTime API is a model of good
design in that regard (and there are better ways for interoperability
with it, as noted in https://news-web.php.net/php.internals/132761).
Only taking a fixed format is already a problem as of now, because
“conditionally omitting the fractional part” is common.

The specified format is interoperable with JavaScript's
Temporal.Instant.from():

 > Temporal.Instant.from('1969-07-20T20:17:40Z')
 Temporal.Instant 1969-07-20T20:17:40Z

 > Temporal.Instant.from('1969-07-20T20:17:40.123456789Z')
 Temporal.Instant 1969-07-20T20:17:40.123456789Z

 > Temporal.Instant.from('1969-07-20T20:17:40.123000000Z')
 Temporal.Instant 1969-07-20T20:17:40.123Z

With Go’s time.RFC3339Nano:

 t, err := time.Parse(time.RFC3339Nano, "1969-07-20T20:17:40Z")
 fmt.Printf("%+v\n", t) // 1969-07-20 20:17:40 +0000 UTC
 fmt.Printf("%+v\n", err) // <nil>
 t, err = time.Parse(time.RFC3339Nano,

"1969-07-20T20:17:40.123456789Z")
fmt.Printf("%+v\n", t) // 1969-07-20 20:17:40.123456789 +0000 UTC
fmt.Printf("%+v\n", err) // <nil>
t, err = time.Parse(time.RFC3339Nano,
"1969-07-20T20:17:40.123000000Z")
fmt.Printf("%+v\n", t) // 1969-07-20 20:17:40.123 +0000 UTC
fmt.Printf("%+v\n", err) // <nil>

With Java’s java.time.Instant.parse():

 System.out.println(Instant.parse("1969-07-20T20:17:40Z")); //

1969-07-20T20:17:40Z
System.out.println(Instant.parse("1969-07-20T20:17:40.123456789Z"));
// 1969-07-20T20:17:40.123456789Z
System.out.println(Instant.parse("1969-07-20T20:17:40.123000000Z"));
// 1969-07-20T20:17:40.123Z

A dedicated parser/formatter instead

I'd prefer parsing and formatting to live in a dedicated
parser/formatter
API (future scope) rather than on Instant, where it would sit next to
the
other ISO-8601 profiles and custom patterns. If the pair stays on
Instant,
the name should say what it really is (a fixed RFC 3339-like profile),
and
the grammar should be part of what we vote on.

I agree with Larry’s DX argument here. I'd also like to note that the
output format is fixed by the RFC. The input format is less
constrained, but the RFC guarantees that it stays true to its name by
only accepting what ISO-8601 specifies.

until() vs Duration::between()

Was Duration::between(Instant $a, Instant $b) considered? Calculating a
duration feels like Duration's responsibility to me.

That suggestion breaks down when measuring elapsed time with a monotonic
clock. PHP does not support method overloading, so it would need to
become Duration::between(Instant|MonoInstant, Instant|MonoInstant)
which then also allows non-sense combinations.

Smaller things

On 32-bit, Duration only covers about 68 years, so until() is more
limited there than the examples suggest. That's worth a sentence.

Added a note to until()’s docblock.

Duration uses sign-magnitude for its (seconds, nanoseconds) pair,
while fromUnixTimestamp(-1, 500_000_000) uses floor semantics (-0.5s).
Both are defensible, but the RFC should say why they differ.

Yes, the Unix timestamp needs “floor semantics” due to external
constraints: The second part only ticks once the full second has
elapsed. Negative Unix timestamps are also comparatively rare and not
always well-defined (e.g. POSIX does not specify a negative time_t).
This is different for Duration where negative values can regularly
appear and where direct interaction with the properties is the expected
use case.

Best regards
Tim Düsterhus

[RFC] Scope

Thu, 29 Oct 2026 12:22:04 +0000

The examples will avoid the PFA form, though, because it reads like a call,
and the difference between running code in the scope and running it before
the scope is entered is three dots:
$scope->run(doAThing(1, 2, 4, ...)); // doAThing runs in $scope
$scope->run(doAThing(1, 2, 4));      // doAThing runs in the caller's scope;
                                     // run() gets whatever it returned

I'd request at least one example somewhere that shows using the PFA form, if only to clarify that it's legal and valid. (Whether it's optimally readable is a more subjective question I'm fine not addressing here.)

"A scope keeps no link to the scope it was run from." So that fully
precludes getParentScope() and such, yes? What is the reason?

It's simple to add in userspace with a WeakMap<Scope, Scope>, for code that
wants a hierarchy. In core it would carry a risk of memory leaks: an app
designed to create each new scope from the previous one, millions of times,
would keep the whole chain alive.

That's valid. Please include that in the RFC.

I think you mean "PHP process" here

Under the CLI the root scope is the process, yes. Under php-fpm it is the
request, not the process, which handles many requests. I'll spell out both
cases instead of saying "request".

Yeah, the terminology here is going to be tricky, but important to be extremely clear on. "request" already means a half dozen things today depending on context, so maybe it's best to avoid it where possible in the RFC?

Am I correct in summarizing it as "a closure inherits the scope of its
callsite, not creation site"?

Yes. Closures don't have a scope; stack frames do. A closure is just code:
while it runs, some scope is current, and later the same closure can run
while another scope is current. What matters is the scope that called it,
since the scope never changes while a function's instructions are running.

Fibers and generators look different, but follow the same rule:

A fiber gets a scope because it will get a stack frame as soon as
$fiber->start() is called. It is bound to the scope that created it, so
it starts in that scope, whoever starts or resumes it.

A generator function is just a function and isn't bound to a scope. But
a Generator is, in a sense, a stack frame: calling the function creates
it, so the Generator object (not the generator function) is bound to the
scope it was created in.

I'll add examples for each.

Ah, so a rule of "scope is bound at stack-frame-creation-time" is a useful global rule to state explicitly, then explain how it applies to various scenarios. That would help clarify the logic, methinks.

For secondary vote A (the superglobals), the example is very unclear.
[...] Forget to do so and poof

$request and $handler are the server's own; I'll make that explicit. The
copying is not something applications do. It is done once, by whatever
creates the request scope: Swerve, FrankenPHP, RoadRunner. That is the same
place that fills the superglobals today.

A new scope starting with empty superglobals is deliberate. Scopes are a
new feature, and it seems safer to start the scope's globals empty and
require frameworks to populate them, than to start them as clones of the
parent's. Clones would let a parent scope mutate values inside its child
scopes through object properties, and every framework would have to clear
them out first.

I'm not clear how the parent scope could mutate values inside the new scope.

My concern is this sort of case:

function legacyLogic(string $message)
{
print $message . ', ' . $_GET['name'];
}

If that is run today, it works. (It's dumb, but it works.)

However, if we do this:

new Scope()->run(legacyLogic('Hello', ...));

Then inside the scope $_GET['name'] no longer exists, so poof, it no longer works. And in a non-trivial scenario, legacyLogic() could be called 20 functions deep, so it's nearly impossible to know that it exists. It means as the scope creator I need to always do something like this, just in case:

$get = $_GET;
$post = $_POST;
$request = $_REQUEST;
$server = $_SERVER;
new Scope()->run(function () use($get, $post, $request, $server) {
$_GET = $get;
$_POST = $post;
$_REQUEST = $request;
$_SERVER = $server;
legacyLogic('hello');
});

Needing to write lots of boilerplate like that "just in case" is a red flag in my mind. Moreover, if the secondary vote doesn't pass initially but is introduced in some later version, it becomes a BC break for anything using a superglobal that happens to be called from within a scope, something the function (by design) doesn't know.

Not cloning feels like a footgun. I would think initializing with a clone of the parent scope and letting the scope setup code modify it if desired would be the safer option, and require less work.

The first mention of $GLOBALS is in the superglobal secondary vote
section. [...] I am undecided if I agree globals should not follow the
scope.

I'll move that up. Globals and static properties stay shared because
applications use them for caches, registries and singletons. Warming those
once and keeping them across requests is the reason to run in worker mode
at all. If they followed the scope, every request would start cold.

That's a valid argument, but both are also frequently used for request-specific caches today. (Global current user, or a static cache that derives from request-sensitive data, etc.) Those would suddenly become buggy if there's multiple scopes happening and the code isn't prepared for it.

Thought: Would a scoped keyword on a static property or global (maybe just static property) be useful, to easily separate that data by scope rather than needing to reengineer it to use a WeakMap? Basically automating the WeakMap logic.

I suppose that wouldn't help with BC anymore than telling people to use getCurrent() would, but it's something. BC would require doing it via an attribute, and I don't know if there's appetite for that.

Something like:

class Foo {
#[Scoped]
private static $cache;

public function getFoos() {
    return $this->cache ??= $this->computeFoosRequestSensitive();
}

}

Which simply automates the WeakMap logic that everyone would need to replicate anyway, while also being backward compatible with existing code.

Other thought: We already have a magic syntax for "the current object scope": $this. Would it make sense to have some other first-class syntax for Scope::getCurrent() that is more compact and self-descriptive? $scope almost certainly wouldn't work for BC reasons, but maybe a keyword?

However, I am still uneasy about how narrow it is. [...] I also fear that
the result is we'll have a lot of subtly-different and incompatible ways
of handling that

That is what we have today, and it's why I wrote this. I spent two years
trying to do it in userspace with phasync. phasync attaches a context to
each fiber and that context follows every child fiber. It almost works,
but not quite:

I'm sold on the use case, and the more I think about it the more sold I am. It's more that I'm torn on this point:

Scope could store values, but then it could quickly become a kind of
service locator and encourage poor design. A WeakMap keyed on Scope
avoids naming conventions for keys, and it limits who can reach
something like a database connection: only the code holding the map.

which is a concern I completely share! I don't think $scope->attributes['good luck keeping these straight'] is the right answer either. My concern is if everyone needs to write their own WeakMap routines, it is very likely that at least a third of them will be subtly wrong in some way. The #[Scoped] attribute above might go a long way to mitigating that concern, but it requires some more consideration.

Also, if we just "magically" separate the superglobals or locale or timezone or whatever, it's not obvious that something has been separated. As the list of things that are separated grows with future RFCs, that could introduce subtle behavior breaks that only show up when code is used in a scope, as in the $_GET example above.

There will be bugs, but not necessarily subtle ones. When one process
handles 5000 concurrent requests, you can't hand out 5000 PDO
connections; you need a limit on the total and a pool. Scope doesn't
cause that class of bug. High concurrency does, and the community will
have to learn to work with it, as Java, C#, Node and Python did.

That's going to be fun to deal with... Are there good examples we can point to to help PHP collectively wrap its head around that pattern faster?

In none of these do classes look services up through the request
identity: they still get their dependencies through the constructor. PHP
has no such identity today, and that is all the primary vote adds.

This is a complete PSR-11 container with the three lifetimes:
final class Container implements Psr\Container\ContainerInterface
{
    private array $shared = [];
    private WeakMap $scoped;   // Scope => that scope's services

    /** @param array<string, array{Closure(self): mixed, 
'singleton'|'scoped'|'transient'}> $services */
public function __construct(private array $services)
{
$this->scoped = new WeakMap();
}
    public function get(string $id): mixed
    {
        [$make, $lifetime] = $this->services[$id] ?? throw new 
NotFound($id);
        if ('scoped' === $lifetime) {
            $mine = $this->scoped[Scope::getCurrent()] ??= new 
ArrayObject();
            return $mine[$id] ??= $make($this);
        }

        return 'singleton' === $lifetime ? $this->shared[$id] ??= 
$make($this) : $make($this);
}

This is the sort of code I fear everyone doing slightly differently and half of us getting it slightly wrong.

If I understand correctly, it would also then be incumbent on the container to ensure that a service that depends on a scoped service is itself scoped. If it doesn't, that sounds like Weird Things(tm) could happen. (As in my database example below.)

    public function has(string $id): bool
    {
        return isset($this->services[$id]);
    }
}
A singleton is built once per worker, a scoped service once per request,
and the request's services are freed with its scope, without the container
ever hearing that the request ended.

For your case, your services stay singletons and are built once per
worker. Only the connection is resolved per request, which is what
Spring's scoped proxy does:
final class TenantConnection
{
    private WeakMap $byScope;

    public function __construct(private Closure $open)
    {
        $this->byScope = new WeakMap();
    }

    public function pdo(): PDO
    {
        return $this->byScope[Scope::getCurrent()] ??= ($this->open)();
    }
}
$open looks at the current request's host (from $_SERVER['HTTP_HOST']
under vote A, or the framework's request object) and connects to that
customer's database. Every service downstream depends on TenantConnection,
not on a PDO, so none of them is recreated. That is also the one rule, as
in .NET: a singleton must not keep a scoped service it got in its
constructor.

Doctrine is the one place to be careful: the EntityManager holds request
state (the identity map and the unit of work), so it has to be scoped too,
or entities leak between customers. The expensive parts, metadata, proxies
and configuration, stay shared.

So the way to do it would be to have a non-scoped factory layer that implements the Connection interface (and a second one that implements the EntityManager interface) and passes all requests on to a scope-sensitive instance. And the factory would need to be externalized so that it could check the current scope itself? Something like:

class ConnectionProxy implements ConnectionInterface {
private WeakMap $conns;

 public function __construct(private Closure $open) {}

public function executeQuery(string $q, array $args) {
    $this->getScopedConn()->executeQuery($q, $args);
}

private function getScopedConn() {
    return $this->conns[Scope::getCurrent()] ??= ($this->open)();
}

}

$conn = new ConnectionProxy(function () {
$domain = $_SERVER['domain'];
// Logic to pick the DB here.

return DriveManager::getConnection(blah);

});

Give or take the pool management you mentioned before.

This is what I'm concerned about. That looks tricky to get right. Eg, it looks like I totally forgot to manually initialize the WeakMap in the constructor. But I suspect this pattern will be common, not just for databases but also for any user-specific objects that get created, like a connection to someone's Mastodon account or whatever. So this is a pattern we need to work to make as fool-proof as possible, because we're all fools. :-)

Continuing my brainstorming from above:

class ConnectionProxy implements ConnectionInterface {
#[Scoped]
private Connection $conn;

 public function __construct(private ConnectionMaker $open) {}

public function executeQuery(string $q, array $args) {
    ($this->conn ??= $this->open())->executeQuery($q, $args);
}

}

class ConnectionMaker {
public function __invoke() {
$domain = $_SERVER['domain'];
// Logic to pick the DB here.
return DriveManager::getConnection(blah);
}
}

That's still not ideal, but has notably fewer moving parts to screw up.

Though thinking about it, passing a PSR-7 request object to the ConnectionMaker would make it not scope-sensitive; It would have to work through the superglobals, or some other global call to get a request object. I'm seeing turtles all the way down here, which has me nervous.

As I said, still in favor of the concept, but I want to make sure we go down these rabbit holes to ensure the turtles don't get too deep. (Boy that's an abused metaphor...)

--Larry Garfield

[RFC] Scope

Thu, 29 Oct 2026 00:09:03 +0000

do we still want to have run(callable, ...$args)? run(Closure $c) would
work just as well

My preferred way to write it is an arrow function, which shows exactly what
runs inside the scope:

$scope->run(fn() => doAThing(1, 2, 4));

But run(doAThing(...), 1, 2, 4) is consistent with the other core APIs:
Fiber::start(), call_user_func(), register_shutdown_function() and many
more take the same "$fn, ...$args" pair. Moving away from that pattern
seems worthy of a separate RFC, and I don't think the Scope RFC should be
the first to break ranks.

It also combines with PFA better than run(Closure $c) would:

function func(int $a, int $b): void {}

// run(Closure $c):
$scope->run(fn() => func(1, 2));  // works
$scope->run(func(1, 2, ...));     // works
$scope->run(func(1, ...));        // fails: $b is missing

// run(callable $c, mixed ...$args):
$scope->run(func(...), 1, 2);     // works
$scope->run(func(1, ?), 2);       // works
$scope->run(fn() => func(1, 2));  // works

Every form that works with a closure-only run() works with this one too,
and a partial application with open parameters only works with this one.

The examples will avoid the PFA form, though, because it reads like a call,
and the difference between running code in the scope and running it before
the scope is entered is three dots:

$scope->run(doAThing(1, 2, 4, ...)); // doAThing runs in $scope
$scope->run(doAThing(1, 2, 4));      // doAThing runs in the caller's scope;
                                     // run() gets whatever it returned

The docblock on Scope::bind() is horribly confusing and clumsy.

Agreed, I'll rewrite it. And yes, it is the Closure::bind() idea: it wraps
a closure in an explicit scope, and returns a new closure that always runs
in that scope, whoever calls it. That is sometimes useful, for example when
the closure needs dependency injection from the scope it came from rather
than from the scope it ends up being called in.

"A scope keeps no link to the scope it was run from." So that fully
precludes getParentScope() and such, yes? What is the reason?

It's simple to add in userspace with a WeakMap<Scope, Scope>, for code that
wants a hierarchy. In core it would carry a risk of memory leaks: an app
designed to create each new scope from the previous one, millions of times,
would keep the whole chain alive.

I think you mean "PHP process" here

Under the CLI the root scope is the process, yes. Under php-fpm it is the
request, not the process, which handles many requests. I'll spell out both
cases instead of saying "request".

Am I correct in summarizing it as "a closure inherits the scope of its
callsite, not creation site"?

Yes. Closures don't have a scope; stack frames do. A closure is just code:
while it runs, some scope is current, and later the same closure can run
while another scope is current. What matters is the scope that called it,
since the scope never changes while a function's instructions are running.

Fibers and generators look different, but follow the same rule:

A fiber gets a scope because it will get a stack frame as soon as
$fiber->start() is called. It is bound to the scope that created it, so
it starts in that scope, whoever starts or resumes it.
A generator function is just a function and isn't bound to a scope. But
a Generator is, in a sense, a stack frame: calling the function creates
it, so the Generator object (not the generator function) is bound to the
scope it was created in.

I'll add examples for each.

For secondary vote A (the superglobals), the example is very unclear.
[...] Forget to do so and poof

$request and $handler are the server's own; I'll make that explicit. The
copying is not something applications do. It is done once, by whatever
creates the request scope: Swerve, FrankenPHP, RoadRunner. That is the same
place that fills the superglobals today.

A new scope starting with empty superglobals is deliberate. Scopes are a
new feature, and it seems safer to start the scope's globals empty and
require frameworks to populate them, than to start them as clones of the
parent's. Clones would let a parent scope mutate values inside its child
scopes through object properties, and every framework would have to clear
them out first.

The first mention of $GLOBALS is in the superglobal secondary vote
section. [...] I am undecided if I agree globals should not follow the
scope.

I'll move that up. Globals and static properties stay shared because
applications use them for caches, registries and singletons. Warming those
once and keeping them across requests is the reason to run in worker mode
at all. If they followed the scope, every request would start cold.

However, I am still uneasy about how narrow it is. [...] I also fear that
the result is we'll have a lot of subtly-different and incompatible ways
of handling that

That is what we have today, and it's why I wrote this. I spent two years
trying to do it in userspace with phasync. phasync attaches a context to
each fiber and that context follows every child fiber. It almost works,
but not quite:

A generator passed from one request to another, concurrent request can
produce one value in one fiber and the next in another. A fiber can't
serve as identity from userspace unless developers pass an
identification token as an argument everywhere.
Amp, React and phasync can each provide some identity tying code to a
request/response pair. But then every third-party library has to pick
one, React or Revolt or something else, integrate with it, or add an
adapter layer. That is the incompatibility you describe, and it exists
precisely because core has no such identity.
In core it is nearly free. It is fast in ext-scope and slow in
userspace.
It makes superglobals less global, which has been one of the main
criticisms of PHP for more than a decade.
Scope could store values, but then it could quickly become a kind of
service locator and encourage poor design. A WeakMap keyed on Scope
avoids naming conventions for keys, and it limits who can reach
something like a database connection: only the code holding the map.
There will be bugs, but not necessarily subtle ones. When one process
handles 5000 concurrent requests, you can't hand out 5000 PDO
connections; you need a limit on the total and a pool. Scope doesn't
cause that class of bug. High concurrency does, and the community will
have to learn to work with it, as Java, C#, Node and Python did.

But the RFC examples are all doing a pseudo-global service locator, not
something I am able or willing to do. [...] So what would it look like in
a real dependency injection situation?

That's a fair objection, and the examples are to blame: I wrote them to
show the mechanism in as few lines as possible, and they ended up looking
like a service locator. I'm not proposing one, and I'll replace them with
a container example.

Scope supports the service locator pattern and dependency injection alike;
it doesn't care which one a framework chooses. I think the confusion comes
from where the scope lives. Functions and closures are not bound to a
scope, and neither is the DI container: it isn't bound to the root scope
just because it was built there. When the container is invoked, the call
goes on the stack with the current scope, so the container sees the scope
it was called from.

That lets a container offer what .NET calls a scoped lifetime: a service
that is neither a singleton shared by all requests nor a transient, but
one instance per request, shared by everything inside that request. The
container keeps those instances in a WeakMap keyed on the Scope, which
users never see.

This is how other languages do it. The runtime gives each unit of work an
identity that follows it across async boundaries, and the container, not
application code, uses it:

.NET: AsyncLocal<T> flows with the ExecutionContext across awaits.
Microsoft.Extensions.DependencyInjection has ServiceLifetime.Scoped,
ASP.NET Core creates one IServiceScope per request, and the container
can refuse a scoped service injected into a singleton (ValidateScopes).
Java: Spring's @RequestScope and CDI's @RequestScoped. A singleton gets
a proxy and calls it normally, and the proxy finds the current request's
instance through a ThreadLocal (RequestContextHolder in Spring).
ScopedValue (JEP 506) is the newer primitive for this, and works with
virtual threads.
Node: AsyncLocalStorage. NestJS has request-scoped providers
(Scope.REQUEST), awilix has createScope(). TC39's AsyncContext proposal
would put the same thing in JavaScript itself.
Python: contextvars (PEP 567), which asyncio copies into every task.
Async frameworks and DI libraries keep request-scoped state in it.
Go passes context.Context explicitly as the first argument everywhere.
That is the alternative, and it is the "identification token as an
argument everywhere" PHP code would need without this RFC.

In none of these do classes look services up through the request
identity: they still get their dependencies through the constructor. PHP
has no such identity today, and that is all the primary vote adds.

This is a complete PSR-11 container with the three lifetimes:

final class Container implements Psr\Container\ContainerInterface
{
    private array $shared = [];
    private WeakMap $scoped;   // Scope => that scope's services

    /** @param array<string, array{Closure(self): mixed, 'singleton'|'scoped'|'transient'}> $services */
    public function __construct(private array $services)
    {
        $this->scoped = new WeakMap();
    }

    public function get(string $id): mixed
    {
        [$make, $lifetime] = $this->services[$id] ?? throw new NotFound($id);

        if ('scoped' === $lifetime) {
            $mine = $this->scoped[Scope::getCurrent()] ??= new ArrayObject();

            return $mine[$id] ??= $make($this);
        }

        return 'singleton' === $lifetime ? $this->shared[$id] ??= $make($this) : $make($this);
    }

    public function has(string $id): bool
    {
        return isset($this->services[$id]);
    }
}

A singleton is built once per worker, a scoped service once per request,
and the request's services are freed with its scope, without the container
ever hearing that the request ended.

For your case, your services stay singletons and are built once per
worker. Only the connection is resolved per request, which is what
Spring's scoped proxy does:

final class TenantConnection
{
    private WeakMap $byScope;

    public function __construct(private Closure $open)
    {
        $this->byScope = new WeakMap();
    }

    public function pdo(): PDO
    {
        return $this->byScope[Scope::getCurrent()] ??= ($this->open)();
    }
}

$open looks at the current request's host (from $_SERVER['HTTP_HOST']
under vote A, or the framework's request object) and connects to that
customer's database. Every service downstream depends on TenantConnection,
not on a PDO, so none of them is recreated. That is also the one rule, as
in .NET: a singleton must not keep a scoped service it got in its
constructor.

Doctrine is the one place to be careful: the EntityManager holds request
state (the identity map and the unit of work), so it has to be scoped too,
or entities leak between customers. The expensive parts, metadata, proxies
and configuration, stay shared.

If you want to see it in practice, this is a complete app for Swerve
(https://github.com/phasync/swerve), using ext-scope's superglobals:

&lt;?php // swerve.php
while (Swerve\Swerve::accept(null, function () {
    $before = $_GET['name'] ?? '-';
    usleep(500_000);   // other requests run in this worker meanwhile
    $after = $_GET['name'] ?? '-';
    echo "before=$before after=$after\n";
})) {
}

$ composer require phasync/swerve
$ vendor/bin/swerve --workers=1 swerve.php

(Swerve loads the extension phasync bundles, which includes ext-scope.)

With one worker, 20 concurrent requests with ?name=req1 to ?name=req20 all
finished in 0.54 seconds, so they really overlapped. Each one printed its
own name before and after the sleep. No request object and no container:
just $_GET, which every request sees as its own.

Frode

[RFC] Scope

Wed, 28 Oct 2026 21:58:18 +0000

Hi internals,

I'd like to start the discussion on a new RFC:

https://wiki.php.net/rfc/scope

PHP has no object that represents a request. The request is the period
between startup and shutdown, and its state lives in process-wide
globals. That works while a process handles one request at a time, but
not when one process serves many requests, and least of all when they
overlap.

The RFC adds Scope: an object that identifies a unit of work, such as
an HTTP request, a queue job or a CLI command. Code can create a scope,
run code in it, and ask which scope it is running in:
(new Scope())->run($handler, $request);

// anywhere in that request:
$db = $this->connections[Scope::getCurrent()] ??= new PDO($dsn);
Fibers and generators join the scope they are created in, so work a
request spreads over several fibers still belongs to that request,
whichever library or scheduler created them. Code that never creates a
scope runs in the root scope and behaves exactly as today.

The primary vote adds only the identity. Two secondary votes move
engine state into the scope:

A. the request superglobals and the session
B. the default locale and timezone

Other state (output buffers, error handlers, ini values) is left for
later RFCs, so each can be discussed on its own.

An extension implementing the RFC, including both secondary votes, is
available for PHP 8.2 to 8.5:

https://github.com/fiber-interop/ext-scope
(pie install fiber-interop/ext-scope)

A userland polyfill is fiber-interop/scope on Packagist. A php-src
pull request will follow before the vote.

I look forward to your feedback.

Frode Børli

Minor thoughts as I read through it:

Given that we now have PFA, which means turning pretty much any call into a closure involves just adding ... to it, do we still want to have run(callable, ...$args)? run(Closure $c) would work just as well, and be callable like

$scope->run(doAThing(1, 2, 4, ...));

I'm not certain here, but it's worth considering if we can go a step further now.

The docblock on Scope::bind() is horribly confusing and clumsy. It took me 5 reads to understand what it was saying. I think the idea is to "change" the scope object inside a closure, just like Closure::bind() changes the $this object inside a closure. Yes? (And returns new rather than modifying in place, but...)
"A scope keeps no link to the scope it was run from." So that fully precludes getParentScope() and such, yes? What is the reason for avoiding that? (Not that I disagree, but I want to understand why.)
"The root scope is a single object that lives as long as the PHP request:" - I think you mean "PHP process" here, as the process is not always isomorphic with an HTTP request. (Which is the whole reason this proposal exists.)
The phrasing and descriptions around closures and what scope they run in is quite confusing. It really needs better examples. Am I correct in summarizing it as "a closure inherits the scope of its callsiite, not creation site"?
For secondary vote A (the superglobals), the example is very unclear. You're useing $request and $handler, but those are never defined. It looks like you're providing no alternative API or automation; really just an under the hood separation of $_GET based on scope. While I can see the simplicity of that, it also means that basically every scope start would need to do the same copying, unless it was absolutely certain there was no code that will be run it that tries to read those superglobals. Forget to do so and poof, some legacy garbage function that reads $_POST directly now gets no data and you don't know why. This feels like a footgun.
The first mention of $GLOBALS is in the superglobal secondary vote section. Are globals and thus $GLOBALS automatically scoped regardless? That should be clarified.
Oh, that's mentioned further down in the "what follows scope" section. That should come way earlier. :-) I am undecided if I agree globals should not follow the scope. That feels like the sort of thing you would want to follow scope.

Overall, I think this is a promising approach. I like that it is narrowly and tightly focused. However, I am still uneasy about how narrow it is. I can see the argument for "make your own WeakMap and go away" as an approach. But I also fear that the result is we'll have a lot of subtly-different and incompatible ways of handling that (say, a multi-fiber server like AmPHP, a DI Container, and a specific service that does weird things for reasons), which could lead to hard-to-diagnose bugs. I am undecided here.

As a concrete use case that I have been actively pondering of late: At work, we have an app that switches which DB it connects to per-request, based on the Customer that is specified through the domain name. (Right now it routes through an env var to a constant, but that I could change.) That works fine in FPM mode, but would fail horribly in FrankenPHP Worker mode. Scopes seem like they're the solution to that problem, but I'm not completely clear how they'd operate in practice in that case. I wouldn't want a different DB connection to cause every service downstream from it to be recreated on every soft-request, as that eliminates the main advantage of worker mode. But the RFC examples are all doing a pseudo-global service locator, not something I am able or willing to do. (I doubt I could coax Doctrine into working that way.) So what would it looks like in a real dependency injection situation?

--Larry Garfield

Proposal for Discussion: Effect Declarations and Capability-Gated Process Execution in PHP

Wed, 28 Oct 2026 15:51:29 +0000

"Effect systems" are a very specific thing in comp sci research. I'm not sure that what is proposed here counts as such. (Think exceptions that return to their point of throw after the handler completes. It seems mainly useful as a way to keep a routine technically-pure while still letting it do useful things.) There are some academic Haskell-like languages with it, but I don't know of anything in widespread use.

What is described here feels more like gated capabilities, similar to what Wasm does. It is an interesting concept, but for it to work it would need to integrate at a very low level. The engine would need to explicitly fail a function that tries calling print without the "I do output" flag, or opening a process without the "I start processes" flag, or reading from the file system without the "I read files" flag. The biggest issue there is, unsurprisingly, backward compatibility. A new PHP release that fails on any function that has a print or fopen statement in it until you add new syntax not available in earlier versions is a complete non-starter.

Yeah, these don't seem quite like algebraic effects. I think there is some modern interest in them again (i.e. Unison), so I would pick a different term to describe them. Capabilities also imply something more like an object capability system to me, so I would also avoid that term.

Proposal for Discussion: Effect Declarations and Capability-Gated Process Execution in PHP

Wed, 28 Oct 2026 15:41:24 +0000

Hi Arsan,

I find the idea interesting, but I have two questions:

Why introduce new syntax instead of using PHP attributes? Isn't this
exactly the kind of metadata that attributes were designed for? What
would be the advantage of introducing a new language construct?

Are you aware of any existing implementations of a similar effect
system in other programming languages? I'd be interested to see how
other languages approach this problem and whether there are any
established patterns PHP could build upon.

Best regards,
Damian

Please do not top post.
Attributes would be useful for static-analysis level enforcement. Something like:

#[AllowedEffects(AllowedEffects::Output)]
function doesAThing(string $thing) {
print $thing;
}

And then an SA tool could object if a print statement appears in a method without that attribute on it. That could be implemented today by any of the SA tools in the ecosystem (though they seem to prefer docblock comments to attributes, unfortunately).

If we wanted something that is enforced by the language, however, then it would need either a language-enforced attribute or new native syntax. And the general zeitgeist is that Internals favors new syntax over attributes for things that have a guaranteed-impact rather than just an optional add-on.

"Effect systems" are a very specific thing in comp sci research. I'm not sure that what is proposed here counts as such. (Think exceptions that return to their point of throw after the handler completes. It seems mainly useful as a way to keep a routine technically-pure while still letting it do useful things.) There are some academic Haskell-like languages with it, but I don't know of anything in widespread use.

What is described here feels more like gated capabilities, similar to what Wasm does. It is an interesting concept, but for it to work it would need to integrate at a very low level. The engine would need to explicitly fail a function that tries calling print without the "I do output" flag, or opening a process without the "I start processes" flag, or reading from the file system without the "I read files" flag. The biggest issue there is, unsurprisingly, backward compatibility. A new PHP release that fails on any function that has a print or fopen statement in it until you add new syntax not available in earlier versions is a complete non-starter.

As noted, it would also need some way to specify a resource dynamically; the file path accessed will be defined at runtime, for instance. In the case of Wasm, the runtime itself passes the path to use INTO the application, chroot-style. (At least I think that's how it works; I'm going off of memory of reading the docs a while back.) I don't see how PHP could get there without completely unacceptable BC breaks.

So I like the idea in the abstract, but the first and most important question is how to make something like this piecemeal opt-in and still meaningful. Because if we can't do that, then we can't do it period.

--Larry Garfield

[RFC] openssl_get_channel_binding

Wed, 28 Oct 2026 14:18:12 +0000

I have created an RFC to add the function openssl_get_channel_binding:
https://wiki.php.net/rfc/openssl_get_channel_binding

PR: https://github.com/php/php-src/pull/24035

The function exposes data related the an established TLS connection,
making it possible for applications to build on top of the security
provided by TLS. It is needed for SASL mechanisms such as
SCRAM-SHA-256-PLUS.

Thank you for the RFC. I have given it a read. First things first: Don't
forget to adjust the RFC Status to “Under Discussion” and to link the
discussion thread (https://news-web.php.net/php.internals/132941).

Content-wise:

“The function returns null when the requested type is not applicable
to the connection.”

An operation that is not applicable sounds like an Exception to me. Is
there currently any other situation where null is returned?

Edit: I'm noting that this is already listed under “Rejected Features”.
I'm not sure I agree with the reasoning, though: Exceptions are the
standard way of indicating unsupported operations / error situations and
the Exception hierarchy is specifically designed to be caught.

“$stream is a stream, but it has no active OpenSSL TLS transport”

That sounds like a programmer error, thus Openssl\OpensslError (or
potentially ValueError).

“An OpenSSL call fails while computing the value”

Is this one reachable in practice or is this more of a generic “catch
all” error that cannot really happen?

“Because the second parameter is an enum, the function itself no
longer has an unknown-type error. […]”

This paragraph should probably not be mentioned in the RFC since it
effectively describes a prior version of the PR / describes how enums
work.

“The backing values preserve interoperability: $type->value is the
IANA name, so it can be forwarded to SASL or other protocol code
unchanged.”

This indeed seems to be a rare case of a backed enum being the right
choice.

“Userland code that declares a function with the same name without a
function_exists() guard would fail with “Cannot redeclare function
openssl_get_channel_binding()”

As I had noted in https://news-web.php.net/php.internals/132938, a
function_exists() check is no guarantee that the code keeps working,
because the previous userland implementation might do something else.
That should be rephrased - but of course openssl_*() is reserved by
ext/openssl and defining new symbols is explicitly acceptable as per
policy.

RFC Impact to “To Existing Extensions”

Are there perhaps any extensions that might want to make use of the new
functionality internally? For example pdo_pgsql, I'm noting that the RFC
mentions tests against PostgreSQL?

Best regards
Tim Düsterhus

[RFC] array_partition()

Tue, 27 Oct 2026 16:24:02 +0000

Hi Tim,

Please do not "top post".

Sorry about that, noted.

One hint for the Wiki: Using <php> around code will perform the proper
escaping, and will also enable syntax highlighting.

Thanks, I've switched that bullet to <php>.

Can you please add another "edge case"
example that clearly shows the reference handling behavior to make sure
every reader is aware of the full implications.

Done, in a new "By-reference elements" subsection. It shows that
writing through the result changes the input (and the other way
round), and that a reference which is no longer shared is copied as a
plain value. The outputs in the examples come from running them against
the implementation.

I'm also not sure, I like the fact that array_partition() has behavior
that cannot be replicated in userland. I can see the "follow
array_filter()" argument for consistency, but at the same time
array_find() is dropping references (I believe)

You're right about array_find(). I checked the other functions in
ext/standard to see where array_partition() would fit:

keep references:  `array_filter()`, `array_diff_key()`, `array_slice()`,
                  `array_values()`, `array_chunk()`
drop references:  `array_find()`, `array_map()`

So the functions that return part of their input as an array all keep
references. array_find() returns a single value, which can't hold a
reference anyway. I think the strongest argument for keeping them is
that replacing the current array_filter() + array_diff_key() idiom with
array_partition() then doesn't change behaviour.

That said, your point about userland replicability is fair, and
dropping references would be a one-line change. I've added it to "Open
Issues" so it gets settled before a vote, and I'm happy to go with
whatever the list prefers.

Best regards,
Ayoub

[RFC] array_partition()

Tue, 27 Oct 2026 16:00:05 +0000

Thank you. One note regarding the mailing list: Please do not “top
post”. Put your reply below the quoted original parts of the email you
are replying to and cut the quote to the relevant bits, just like I'm
doing here:

Fixed the "[[], []]" rendering in "Semantics in detail".

One hint for the Wiki: Using <php> around code will perform the proper
escaping, and will also enable syntax highlighting.

Replaced the stub in the proposal with a userland implementation
using foreach. While checking it against the native function, I found
one difference: the native function keeps by-reference elements as
references, like array_filter(), and the foreach version does not.
The RFC mentions it right below the code.

Good that I asked for the example implementation - and that you spelled
out the difference, because I did not realize the significance of the
“By-reference elements of the input are handled in the same way as in
array_filter()” in the “Semantics in detail” section - and there is no
corresponding example either. Can you please add another “edge case”
example that clearly shows the reference handling behavior to make sure
every reader is aware of the full implications.

I'm also not sure, I like the fact that array_partition() has behavior
that cannot be replicated in userland. I can see the “follow
array_filter()” argument for consistency, but at the same time
array_find() is dropping references (I believe) and I also feel that
“filtering an array” (i.e. just removing entries) is semantically
somewhat different than “creating new arrays with the original
elements”. There are probably good arguments for both positions and I'd
like to hear some more opinions from others on this matter.

Best regards
Tim Düsterhus

[RFC] [Discussion] Query Parameter Manipulation Support

Tue, 27 Oct 2026 13:54:30 +0000

Hi Tim,

I don't think QueryParamParsingOptions::$maxQueryStringLength is

necessary or useful to have. Checking the input length is easy to do
manually (it's just a strlen() call) and I don't see a practical way
to abuse the API with large input lengths alone: The API will not “blow
up” inputs into considerably larger data structures, the input strings
are mostly just “copied” over, not too different from e.g.
str_replace().

I was also thinking a lot about whether this option is necessary to have.
My main reason for including it was that people would otherwise easily
forget
to limit the input length, whereas the dedicated option enforces the limit
everywhere.

So the real question is whether QueryParams really cannot be abused via
long strings, and whether $maxParamCount alone could mitigate those risks
?

And now by thinking about it more, neither I could identify any specific
vulnerability that
would become possible by not enforcing the upper limit. In the previous
iteration
of the RFC, limiting the length was more useful, because parsing would
have been
a more resource intensive operation due to the requirements of the old
"array API".
The operations that are performed now during parsing are cheap, so as far
as I can see,
it's possible to get rid of this option if no one can come up with a good
enough use-case.

Just after sending my previous reply, I realized that even if parsing long
query strings
isn't an expensive operation on its own, the rest of the operations
supported by
QueryParams may be. For example, sorting by long keys can cause significant
slowdown.
(To be fair: I haven't done any measurements yet). And in the light of the
recent CVEs,
increased memory consumption can cause troubles, so IMO an automatically
enforced
maximum length can still be useful.

Regarding accepting malformed input: uriparser's own query parameter

handling
functions (uriDissectQueryMalloc*()) behave the same way as the RFC currently
proposes.
Unfortunately, I could not really find any reasoning behind this choice of
uriparser.

To be clear, I don't insist on following uriparser's behavior for RFC 1866
and RFC 3986 (it's
not an option for WHATWG URL, since it specifies what needs to be done in
every detail),
and probably strict parsing is what is more consistent with the Uri class
indeed.

When implementing strict parsing for the RFC-based parsers, I realized that
migration from
the $_GET usage (via Uri\QueryParams::parseRfc1866($_SERVER["QUERY_STRING"]
?? ""))
would be more difficult, because parseRfc1866() would start rejecting
malformed input that
PHP's existing query-string parser (php_default_treat_data()) currently
accepts. I'm not really
sure how big an issue this would be in practice, but at least it's worth
pointing out.

One more thing which I'm probably going to change: it turned out that
WHATWG URL specifies
the sort() method (https://url.spec.whatwg.org/#dom-urlsearchparams-sort)
which must use UTF-16 based
comparisons (using 2 bytes). It is really not obvious from the WHATWG URL,
only the WHATWG Infra
specification defines it:
https://infra.spec.whatwg.org/#code-unit-less-than

In order to restore compatibility with this requirement, I'd define two
sorting algorithms:

sortByBytes(): the currently specified one which would use bytes as the
base of comparison

sortByUtf16(): the one comparing UTF-16 sequences at once which would be
compatible with WHATWG URL

I've now added this to the RFC and also started to implement it (only
locally).

Máté

[RFC] array_partition()

Tue, 27 Oct 2026 10:35:36 +0000

Hi Tim,

Thank you for the careful read, and for the kind words.

I've updated the RFC:

Fixed the "[[], []]" rendering in "Semantics in detail".
Added is_string(?) to the arity example. I verified that it works
with the implementation.
Linked the declined Destructuring Coalesce RFC from the
missing-buckets argument and from "Related RFCs".
Rewrote the first paragraph of "Backward Incompatible Changes": with
or without a function_exists() guard, an existing userland
array_partition() needs to be checked against the native semantics.
Replaced the stub in the proposal with a userland implementation
using foreach. While checking it against the native function, I found
one difference: the native function keeps by-reference elements as
references, like array_filter(), and the foreach version does not.
The RFC mentions it right below the code.

Best regards,
Ayoub

Hi

I'd like to start the discussion on a new RFC:

https://wiki.php.net/rfc/array_partition

Thank you for your RFC. Incidentally a co-worker has hand-written an
array_partition() just last week (using two array_filter() calls),
so clearly there is some appetite for it.

I've just read the RFC and noticed a small rendering issue in the
“Semantics in detail” section. For the “An empty input” bullet point it
seems you didn't properly escape the code and it was interpreted as Wiki
markup.

For the arity example, you could add that is_string(?) with PFA’s ?
placeholder should work, since it behaves like a userland function.

For the “why not a general grouping function” section, I would like to
point towards the declined
https://wiki.php.net/rfc/destructuring_coalesce RFC, which is somewhat
related to the “The buckets are only created when at least one element
falls into them” argument.

For the “Backward incompatible changes” section, I'd like to note that
even for users defining array_partition with a function_exists()
check nothing guarantees that their custom implementation behaves the
same, so they would need to adjust their code either way. This is
acknowledged in the second paragraph, but the initial paragraph is
somewhat misleading. In any case, adding new symbols is not considered a
breaking change as per policy and the arguments for the proposed name
are strong, so this is not a hard blocker (but must be mentioned
nevertheless, as you did).

Perhaps it would also make sense to extend the stub in the proposal
section to a full “userland polyfill” (using the foreach loop), similar
to what the array_find() RFC did. This can help make the behavior
clear in a way that pure prose can't.

Other than these small polishing nits, I don't have anything to remark
about the RFC other than: It's a well-written, well-researched and
well-argued RFC and I'm in favor of the proposal.

Best regards
Tim Düsterhus

Proposal for Discussion: Effect Declarations and Capability-Gated Process Execution in PHP

Tue, 27 Oct 2026 09:38:55 +0000

Hi Arsan,

I find the idea interesting, but I have two questions:

Why introduce new syntax instead of using PHP attributes? Isn't this
exactly the kind of metadata that attributes were designed for? What would
be the advantage of introducing a new language construct?
Are you aware of any existing implementations of a similar effect system
in other programming languages? I'd be interested to see how other
languages approach this problem and whether there are any established
patterns PHP could build upon.

Best regards,
Damian

niedz., 25 paź 2026, 14:42 użytkownik Arsan Gamal arsan.gamal@gmail.com
napisał:

Hello PHP Internals,

I would like to propose an idea for discussion regarding the introduction
of effect declarations in PHP, with a particular focus on making function
behavior more explicit and improving the security and auditability of
sensitive operations.

Currently, PHP function signatures describe parameters and return values
but do not indicate which external operations a function may perform. A
function may execute operating-system commands, access the filesystem, or
make network requests through its implementation or dependencies without
these operations being visible in its signature.

I believe an effect system could help address this limitation by allowing
functions to declare the operations they may perform. These declarations
could support static analysis, contract checking, code auditing, and
potentially stronger security controls.
Proposed syntax

As an initial proposal, effects could be declared alongside a function's
return type:

function generateReport(string $input): string
effects [process.execute]
{
// Implementation
}

Effects could also accept parameters to describe the scope of an operation:

function generateReport(string $input): string
effects [
process.execute(
commands: ['/usr/bin/report-renderer']
)
]
{
// Implementation
}

In this example, the effect declaration indicates that the function may
execute a process, with the declared contract restricting the intended
executable to the report renderer.

The same concept could be extended to other operations:

function readConfiguration(): string
effects [
filesystem.read(
paths: ['/etc/myapp/config.json']
)
]
{
// Implementation
}

function fetchReport(string $url): string
effects [
network.request(
hosts: ['api.example.com']
)
]
{
// Implementation
}

These examples are illustrative and are not intended to prescribe the
final grammar. The syntax, supported effect types, parameter formats, and
enforcement rules would need to be discussed and evaluated.
Effect checking and security

I envision effects serving as explicit contracts describing the operations
a function may perform. A static analyzer or compiler could check whether
implementations and their dependencies respect these declarations, identify
undeclared effects, and make sensitive operations more visible during code
review.

Parameterized effects could provide additional information about the
intended scope of an operation. For example, a function declaring a
process-execution effect restricted to a particular executable could be
checked for attempts to execute other programs.

I would also like to explore how this proposal could complement a
capability-based security model. Effects and capabilities would have
separate responsibilities: effects would describe the operations and
constraints associated with a function, while capabilities would determine
which operations are authorized at runtime.

For example, an application could grant a request handler permission to
execute a specific binary with defined argument constraints and resource
limits. The runtime would enforce that permission when a process is
created, independently of the function's effect declaration.

This distinction is important because declaring an effect should not
automatically grant authority to perform the operation. Runtime enforcement
would remain necessary for security-sensitive operations, even if static
effect checking were available.
Scope and open questions

I recognize that PHP's dynamic features, backward-compatibility
requirements, and native extension ecosystem present significant design and
implementation challenges. Some questions that would need further
exploration include:

Whether effects should be explicitly declared, inferred, or support
both approaches.

How effects should propagate through function calls, closures, dynamic
calls, and third-party dependencies.

How parameterized effects should be represented and validated.

Whether effect contracts should be enforced by the PHP engine,
external static analysis tools, or a combination of both.

How effects could integrate with runtime capabilities and existing
APIs.

How strict enforcement could be introduced without breaking existing
PHP applications.

The proposal would not, by itself, prevent vulnerabilities within the PHP
engine or native extensions. Any runtime security guarantees would depend
on the coverage and correctness of the enforcement mechanisms.

I have started drafting an RFC exploring these ideas, using process
execution as an initial use case. I would welcome feedback on whether
effect declarations and parameterized effects would be a worthwhile
direction for PHP, whether the proposed syntax fits the language, and what
scope would be appropriate for an initial RFC.

If there is interest, I would be happy to share the draft and work on a
proof of concept.

Thank you for your time and consideration.

Respectfully yours,
Arsan Gamal
Senior Software Engineer

[RFC] openssl_get_channel_binding

Tue, 27 Oct 2026 09:25:46 +0000

Hello,

I have created an RFC to add the function openssl_get_channel_binding: https://wiki.php.net/rfc/openssl_get_channel_binding

PR: https://github.com/php/php-src/pull/24035

The function exposes data related the an established TLS connection, making it possible for applications to build on top of the security provided by TLS. It is needed for SASL mechanisms such as SCRAM-SHA-256-PLUS.

Regards,

Sjoerd Langkemper

[RFC] CSV Extension (ext/csv)

Tue, 27 Oct 2026 07:10:49 +0000

Hi Tim,

Thanks for your feedback.

You're right about the timing. I hadn't fully considered the impact of last
week's security release on the availability of contributors. I'm happy to
postpone the vote to allow more time for discussion.

Regarding the namespace, I see your point. I chose "Csv" because it is
simple, clearly describes the functionality, and follows a similar approach
to existing namespaces such as "Uri" and "Dom". However, I'm open to
discussing alternative approaches if a broader naming convention would make
more sense for PHP.

I also agree that hearing from Gina would be valuable.

Thanks again for taking the time to share your concerns.

Best regards,
Damian

pon., 26 paź 2026, 23:05 użytkownik Tim Düsterhus tim@bastelstu.be
napisał:

Hi

The discussion for this RFC started on October 9, and there has been no
further feedback on the mailing list or GitHub for approximately two
weeks.

within those two weeks there was last week’s security release. As with
the Io\Terminal RFC, I suggest to wait with the vote until things have
calmed down.

See also: https://news-web.php.net/php.internals/132895

Unless any new concerns or objections are raised, I intend to open the
vote
on November 2.
I did not have the time to read the RFC due to the above, but one big
concern of mine is the choice of namespace. I'm not sure if “CSV” is an
important and large enough topic to warrant its own core extension and
to reserve another top-level namespace. There might be a way to nicely
group it with something else (e.g. “file format” or ”serialization
format”) and I believe that warrants further discussion and opinion.

I'd also like to hear from Gina as the original author of the extension
you propose for inclusion in core.

Best regards
Tim Düsterhus

[RFC Idea] Formalization moratorium after PHP2Shell (CVE-2026-109618/109619): independent implementations in Rocq/Agda/K/Redex

Tue, 27 Oct 2026 02:46:55 +0000

Hi internals,

Summary:
In October 2026 two critical runtime vulnerabilities, CVE-2026-109618 and
CVE-2026-109619 (PHP2Shell, CVSS 9.2, fixed in 8.2.35 / 8.3.36 / 8.4.27 /
8.5.12 on Oct 21), were found in the Zend Memory Manager and HashTable /
session upload progress handling. Not in ext/dom, ext/curl, or any
application — in the allocator and stale request globals. This affects
essentially every SAPI (FPM, mod_php, CGI, FrankenPHP).

Motivation - mono-implementation brittleness:
PHP is still defined by a single implementation. Efforts like php-langspec
and KPHP were abandoned in the PHP 7 era. Today PHP_CodeSniffer,
PHP-CS-Fixer, and PHP-Parser each maintain their own partial parsers,
PeachPie must add workarounds for Laravel, and HHVM abandoned PHP
compatibility in 2019 to become Hack. Without a second implementation and a
formal spec, we have no way to catch this class of bug early.

Cost of cosmetic deprecations:
We have just deprecated non-canonical casts: (integer) -> (int), (boolean)
-> (bool), (double) -> (float), (binary) -> (string). They are functionally
identical. While well-intentioned for consistency, each such deprecation
forces churn across tooling and user code. That time is not spent on
reinforcing the base — exactly what PHP2Shell shows we need.

Proposal:

Impose an immediate embargo on all new features and all cosmetic
deprecations until the mono-implementation situation is rectified. Not
adding a feature cannot break apps. Not deprecating (integer) cannot break
apps. A corrupt allocator can.

You're asking the maintainers of Zend PHP to stop building Zend PHP and
focus their efforts on building another implementation?

Complete the spec attempt left behind by
【entity-Facebook¦canonical_name=Facebook】 by reading php-src with AI
assistance.

I agree that this spec should be kept up-to-date. Doing so requires
【entity-volunteers¦canonical_name=volunteers】.

Do not do the old ArtCraft-style clone-in-Rust-first approach. Since
this class of bug was found with AI, and AI can now write directly in
formalized languages, I propose we implement directly in formal frameworks:
a) Extract and standardize the two ground truths: Zend Engine bytecode
and the formal parser.
b) Build 4 independent implementations directly: two operational
semantics in K Semantic Framework and Racket PLT Redex, and two mechanized
definitions in Rocq and Agda.
c) Build a PyPy/Roslyn-style compiler from PHP to bytecode/JS from those
definitions to bootstrap semantics.
d) Cross-test all implementations against php-src tests AND WordPress,
MediaWiki, Laravel, and other major codebases.
e) Demonstrate bootstrapping by using the new implementations to compile
the bootstrapped runtime with itself.

This gives us what other mature runtimes have: .NET has CoreCLR and still
keeps a Mono option to stress-test additions; Python has PyPy, Cython,
Brython. PHP needs the same.

The other implementations exist because the communities built them. The
core developers of the reference implementations didn't decide to stop
building their implementation to build the others. You're asking a group
that's already stretched too thin with limited resources to stretch
themselves further to build and maintain competing implementations.

All of this is work that companies with the resources to build these
implementations should be doing, contributing them back to the ecosystem
to solve the problems that you've postulated.

I am not arguing for permanent stasis, only for sequencing: formalize and
diversify first, then resume features. That is how we prevent irrelevance
for greenfield projects.

Thanks,
Brian

Cheers,
Ben

[RFC] array_partition()

Mon, 26 Oct 2026 22:37:24 +0000

I'd like to start the discussion on a new RFC:

https://wiki.php.net/rfc/array_partition

Thank you for your RFC. Incidentally a co-worker has hand-written an
array_partition() just last week (using two array_filter() calls),
so clearly there is some appetite for it.

I've just read the RFC and noticed a small rendering issue in the
“Semantics in detail” section. For the “An empty input” bullet point it
seems you didn't properly escape the code and it was interpreted as Wiki
markup.

For the arity example, you could add that is_string(?) with PFA’s ?
placeholder should work, since it behaves like a userland function.

For the “why not a general grouping function” section, I would like to
point towards the declined
https://wiki.php.net/rfc/destructuring_coalesce RFC, which is somewhat
related to the “The buckets are only created when at least one element
falls into them” argument.

For the “Backward incompatible changes” section, I'd like to note that
even for users defining array_partition with a function_exists()
check nothing guarantees that their custom implementation behaves the
same, so they would need to adjust their code either way. This is
acknowledged in the second paragraph, but the initial paragraph is
somewhat misleading. In any case, adding new symbols is not considered a
breaking change as per policy and the arguments for the proposed name
are strong, so this is not a hard blocker (but must be mentioned
nevertheless, as you did).

Perhaps it would also make sense to extend the stub in the proposal
section to a full “userland polyfill” (using the foreach loop), similar
to what the array_find() RFC did. This can help make the behavior
clear in a way that pure prose can't.

Other than these small polishing nits, I don't have anything to remark
about the RFC other than: It's a well-written, well-researched and
well-argued RFC and I'm in favor of the proposal.

Best regards
Tim Düsterhus

[RFC] CSV Extension (ext/csv)

Mon, 26 Oct 2026 22:05:42 +0000

The discussion for this RFC started on October 9, and there has been no
further feedback on the mailing list or GitHub for approximately two weeks.

within those two weeks there was last week’s security release. As with
the Io\Terminal RFC, I suggest to wait with the vote until things have
calmed down.

Unless any new concerns or objections are raised, I intend to open the vote
on November 2.
I did not have the time to read the RFC due to the above, but one big
concern of mine is the choice of namespace. I'm not sure if “CSV” is an
important and large enough topic to warrant its own core extension and
to reserve another top-level namespace. There might be a way to nicely
group it with something else (e.g. “file format” or ”serialization
format”) and I believe that warrants further discussion and opinion.

I'd also like to hear from Gina as the original author of the extension
you propose for inclusion in core.

Best regards
Tim Düsterhus

Proposal for Discussion: Effect Declarations and Capability-Gated Process Execution in PHP

Mon, 26 Oct 2026 21:38:30 +0000

[IDEA] Native async/await syntax on top of Fibers

Mon, 26 Oct 2026 16:28:35 +0000

Hi Abbas,

Thanks for putting a prototype behind the idea.

I think PHP is already closer to good async than it looks, and that the
best path keeps the property Fibers gave us: no function colouring. Any
function can suspend, and its caller doesn't need to know. That lets
PHP go the way of Go rather than JavaScript: code is written as
ordinary blocking code, and concurrency is chosen at the call site, not
declared on the function.

This runs today, unchanged, on phasync, Revolt, AMPHP, ReactPHP and
Swoole:

use function fiber\{go, await_all, sleep};

function fetchAll(array $ms): array
{
    $tasks = [];
    foreach ($ms as $m) {
        $tasks[] = go(function () use ($m) {
            sleep($m / 1000);
            return "slept $m ms";
        });
    }
    return await_all($tasks);
}

sleep() is just called, with no await. It suspends the task it runs
in, not the process, and fetchAll() is an ordinary function that its
callers can't tell apart from a blocking one.

The only reason it is fiber\sleep() and not \sleep() is that PHP's own
sleep() has no way to tell the scheduler it is about to block. Give
userland a way to be notified when a fiber would otherwise block, and
plain \sleep(), fread() or PDO::query() behave the same way. At that
point there is nothing left for an await on a function call to do.

Compare Async\delay() in your proposal. Without the await,

$value = Async\delay($secs);

doesn't wait at all: $value is a Future, and the code carries on at
once. Every function that returns a Future has that trap, and every
caller has to know which functions are which. That is the colouring,
and it spreads: a library that wants to serve both kinds of code ends
up with two versions of each function.

I read your point that everyone still picks a userland library as a
frustration with interoperability, and I share it. A library written
for Amp doesn't run on ReactPHP. But that is solvable without new
syntax. The code above is from fiber-interop, a small common API with
an adapter per event loop:

https://fiber-interop.github.io/

Most of the remaining pieces exist too. PHP even lets userland make
file I/O transparent: phasync/file-streamwrapper replaces the file://
wrapper, so plain file_get_contents()/fread() code suspends only its
own fiber:

https://github.com/phasync/file-streamwrapper

That works because stream wrappers are a userland extension point.
PDO, curl, mysqli and the socket functions have no such point. What the
language lacks is the interface for them: a standard way for an
internal function that would block the whole process to ask the
userland scheduler to suspend the current fiber, and to be resumed when
its I/O is ready. With that, existing code becomes concurrent without
being rewritten, under whichever event loop the application uses.

If PHP gets async and await keywords some day, I think they should
launch and join fibers at the call site, not mark functions and await
futures:

$fiber = async some_function(1, 2, 3);
$result = await $fiber;

some_function() stays an ordinary function. Whether it runs
concurrently is the caller's choice, as with Go's "go", so nothing is
coloured.

A request that runs in many fibers also needs to know which request it
belongs to. That is Go's context.Context, and it's what I've just
proposed as the Scope RFC:

https://wiki.php.net/rfc/scope

Frode Børli

[RFC] Scope

Mon, 26 Oct 2026 16:03:58 +0000

Hi internals,

I'd like to start the discussion on a new RFC:

https://wiki.php.net/rfc/scope

PHP has no object that represents a request. The request is the period
between startup and shutdown, and its state lives in process-wide
globals. That works while a process handles one request at a time, but
not when one process serves many requests, and least of all when they
overlap.

The RFC adds Scope: an object that identifies a unit of work, such as
an HTTP request, a queue job or a CLI command. Code can create a scope,
run code in it, and ask which scope it is running in:

(new Scope())->run($handler, $request);

// anywhere in that request:
$db = $this->connections[Scope::getCurrent()] ??= new PDO($dsn);

Fibers and generators join the scope they are created in, so work a
request spreads over several fibers still belongs to that request,
whichever library or scheduler created them. Code that never creates a
scope runs in the root scope and behaves exactly as today.

The primary vote adds only the identity. Two secondary votes move
engine state into the scope:

A. the request superglobals and the session
B. the default locale and timezone

Other state (output buffers, error handlers, ini values) is left for
later RFCs, so each can be discussed on its own.

An extension implementing the RFC, including both secondary votes, is
available for PHP 8.2 to 8.5:

https://github.com/fiber-interop/ext-scope
(pie install fiber-interop/ext-scope)

A userland polyfill is fiber-interop/scope on Packagist. A php-src
pull request will follow before the vote.

I look forward to your feedback.

Frode Børli

Updated PHP Windows builds for Brotli security fix

Mon, 26 Oct 2026 15:49:24 +0000

The PHP team announces the immediate availability of updated Windows
builds:

PHP 8.2.35-1
PHP 8.3.36-1
PHP 8.4.27-1
PHP 8.5.12-1

These builds include Brotli 1.2.1, which fixes CVE-2026-111497, an
out-of-bounds write vulnerability in Brotli decompression.

On Windows, PHP's cURL extension can invoke the affected decoder when
automatic HTTP response decompression is enabled. This is disabled by
default in cURL, but applications and HTTP client libraries may enable
it.

PHP Windows users are advised to update to these builds.

The -1 suffix marks a Windows package rebuild with updated dependencies.
The PHP source and runtime versions have not changed.

Release announcement: https://www.php.net/archive/2026.php#2026-10-26-1

Windows downloads: https://www.php.net/downloads.php?os=windows

Regards,
Shivam Mathur

[RFC] CSV Extension (ext/csv)

Mon, 26 Oct 2026 14:52:24 +0000

Hi internals,

The discussion for this RFC started on October 9, and there has been no
further feedback on the mailing list or GitHub for approximately two weeks.

Unless any new concerns or objections are raised, I intend to open the vote
on November 2.

Thanks to everyone who participated in the discussion.

Best regards,
Damian

On Sun, Oct 11, 2026 at 1:50 PM Damian Jóźwiak <
damian.jozwiak.lodz@gmail.com> wrote:

Hi everyone,

Thank you for the feedback, and Artem, for the detailed review and
independent verification of the implementation.

I think the discussion has raised two important questions: whether these
improvements belong in the existing CSV API or a dedicated extension, and
what an API supporting both files and already-open streams should look like.

Artem, your point about incremental improvements is fair. The RFC's
statement that the existing behaviour “cannot be fixed without breaking
compatibility” is too broad. Several improvements could be introduced
through additional functions or opt-in behaviour while preserving existing
calls. You are also right that enclosing fields containing spaces is
permitted by RFC 4180, and that locale-independent byte parsing has
different implications for encodings such as Shift_JIS.

At the same time, PHP has taken the approach of introducing a modern API
alongside an established one when their contracts differ substantially. The
new DOM API, including Dom\Document, coexists with the legacy DOMDocument
API, and the URI extension provides a dedicated API alongside parse_url().
These are relevant precedents for giving users clearer semantics without
changing the behaviour of existing applications. Of course, those
precedents do not automatically justify another CSV parser. They do suggest
that improving the existing API and introducing a dedicated one are both
reasonable approaches to evaluate. The question is whether the consistency
and usability of the proposed CSV API justify its maintenance cost.

My motivation is to provide parsing, serialization, validation and file
handling with consistent, explicit defaults. In particular, the file-based
entry points accept a path and manage the underlying stream, covering the
convenience previously provided by SplFileObject's CSV methods. The
existing fgetcsv()/fputcsv() functions operate on streams supplied by the
caller. Both use cases deserve support.

Separately, the remaining overlapping-token writer issue reported on the
PR has been addressed in
https://github.com/php/php-src/commit/b7866156dc7e77304fe3419edceba6f890b113cb.
Fields are now enclosed when tokens could form across field/separator
boundaries. Distinguishable overlapping dialects remain supported;
ambiguous combinations such as delimiter xy with enclosure xyx are
rejected by both readers and writers. Regression tests cover both
behaviours, and all 92 PHPT tests pass in my local verification.

With those concerns in mind, I would like to discuss three possible
directions:

A. Improve the existing API in ext/standard, adding capabilities such as
string serialization, multibyte tokens and opt-in strict parsing, with file
and lazy-reading conveniences considered where needed.

B. Continue with the dedicated ext/csv proposal, retaining its
function-based API and lazy collection, while adding entry points for
existing streams and resolving the naming questions.

C. Rework the proposal around an object-oriented API in the Csv namespace,
with explicit file and stream factories and writing methods. Stream
ownership, iteration, validation and string conversion would need to be
specified before this became a concrete voting option.

My preference remains a dedicated API with consistent semantics, but I am
open to revising its shape or pursuing the existing-API route if that is
the direction the project prefers.

Would a directional vote between these approaches be useful if discussion
does not establish a clear preference? I would first document the
alternatives and their trade-offs, and agree on the voting format.
Selecting a direction would guide a revised proposal; it would not approve
an API whose details have yet to be reviewed.

The current RFC does not propose deprecating the existing CSV functions.
Any future consolidation would need its own discussion and an established
migration path, rather than assuming that introducing a new API commits PHP
to removing the old one.

The goal is to establish a maintainable CSV path for PHP users, including
those migrating from the deprecated SplFileObject methods. I would welcome
your thoughts on which direction best serves that goal.

Best regards,
Damian

On Sat, Oct 10, 2026 at 12:38 PM Artem Ukrainskiy <
art.ukrainskiy@gmail.com> wrote:

This RFC led me to take a closer look at the built-in CSV functions, and
what I found makes me favor a different path to the same goals.

The RFC argues that their behavior "cannot be fixed without breaking
compatibility". I went through the list:

$escape: already addressed by the PHP 8.4 deprecation; the default
changes to "" in PHP 9.0.

Locale dependence: php/php-src#24207 (
https://github.com/php/php-src/pull/24207, under review, prompted by
this RFC) removes the per-byte libc lookup for ASCII characters in
ASCII-compatible locales. The remaining isspace() before an opening
enclosure can be replaced with an explicit space/tab check. For non-ASCII
bytes in CJK locales, mbrlen() serves a purpose: a Shift_JIS character can
contain a '|' trail byte without that byte being a delimiter. A
locale-independent byte parser would split it.

Single-byte delimiters and enclosures: longer values currently throw
ValueError, so support for multibyte tokens can be added without changing
existing valid calls.

No inverse of str_getcsv(): a str_putcsv() function would fill that gap
and let SplFileObject::fputcsv() callers use
$file->fwrite(str_putcsv($row)).

[null] for an empty line and whitespace before an enclosure: these can
be addressed by an opt-in strict mode without changing the default
behavior. Enclosing fields containing spaces on output is permitted by RFC
4180 section 2.5 and is not a compliance defect.

Strict validation, multibyte tokens, string serialization and lazy
reading can all be built on the existing API. Lazy iteration over a stream
already works with a generator around fgetcsv(); strict row-width
validation can be layered on top. These changes can be developed and
reviewed independently, without replacing the parser or breaking existing
calls.

I have benchmarks and test scripts for the existing implementation and
the proposed extension here:
https://github.com/ArtUkrainskiy/php-src-bench/tree/main/reports/csv-pr-24199

Adding ext/csv instead would leave core maintaining two independent CSV
parsers for the foreseeable future. The RFC explicitly leaves the built-ins
unchanged, and the June discussion around the SplFileObject deprecations
showed understandable reluctance to remove existing APIs without an
established migration path (https://news-web.php.net/php.internals/131503,
and the August follow-up: https://news-web.php.net/php.internals/132186).

The branch itself is in good shape. The issues I reported on the PR were
addressed quickly, and the parser is now faster than fgetcsv() in my
benchmarks. This is not an objection to the implementation or the work that
went into it.

My concern is the long-term maintenance cost of introducing a second
parser when the existing one can be improved incrementally. I'd rather help
land those improvements in ext/standard.

пт, 9 окт. 2026 г. в 17:07, Damian Jóźwiak <damian.jozwiak.lodz@gmail.com

:

Hi internals,

I'd like to open the discussion on an RFC proposing a dedicated CSV
extension (ext/csv) for PHP core.

RFC: https://wiki.php.net/rfc/csv_extension

Implementation: https://github.com/php/php-src/pull/24199

The proposal builds upon Gina Peter Banyard's girgias/csv extension
(BSD-3-Clause), with additional functionality for file and stream handling.

The motivation includes the deprecation of the SplFileObject CSV
methods in PHP 8.6, which leaves certain use cases without a direct
replacement.

The proposed extension provides:

Six functions and one class in the Csv\ namespace.

RFC 4180-compatible parsing and serialization by default.

Locale-independent processing without the proprietary escape
mechanism.

Multibyte delimiters, enclosures, and EOL sequences.

Strict and lax collection parsing.

Lazy iteration over CSV files and streaming output.

The implementation includes PHPT tests covering parsing, serialization,
stream handling, resource lifetime, and various edge cases.

The pull request's CI checks are currently passing across the tested
platforms, including debug, ZTS, and AddressSanitizer configurations.

The initial API is deliberately kept small. A more comprehensive
object-oriented Reader/Writer API, including capability-oriented
interfaces, is left for potential future discussion.

I'd particularly appreciate feedback on the public API design, the
naming of LazyLaxCollection, and whether the extension should be always
enabled or optional at build time.

For transparency, Gina has not reviewed or endorsed this RFC. Parts of
the implementation were developed with LLM assistance; I have reviewed the
code and take full responsibility for the contribution.

This is an invitation for discussion, not a call for votes.

Thanks in advance for your feedback.

Best regards,
Damian Jóźwiak

--
Best regards,
Artem Ukrainskiy

[RFC] array_partition()

Mon, 26 Oct 2026 14:34:14 +0000

Hi mickmackusa,

Instead of potentially creating array_partition() and eventually
array_group(), I feel any benefits of array_partition() should be baked
into an array_group() function for greater utility in a unified function.

Thanks for thinking it through. Seeded keys would indeed solve the
missing-bucket problem, and with string labels the result reads well:

['adults' => $adults, 'minors' => $minors] = array_group(
    $users,
    fn($u) => $u->age >= 18 ? 'adults' : 'minors',
    ['adults', 'minors'],
);

I still think the two-way split deserves its own function, for three
reasons:

Destructuring is by key, not by order. With a boolean callback, the
keys become 1 and 0 whatever order they are seeded in, so
[$adults, $minors] = array_group($users, $predicate, [true, false])
puts the minors in $adults. You have to switch to labels, as above.
With labels, the callback, the seed list and the destructuring keys
have to agree. A typo ('adult' vs 'adults') silently creates a third
group and leaves one variable empty. array_partition() only needs a
predicate, and its result shape is fixed.
PHP already pairs general functions with simpler, specialised ones
for common cases: array_filter() with array_find() and array_any().
A two-way split is common enough to warrant the same treatment.
It doesn't rule out a future array_group(), which raises its own
design questions (return shape, unknown keys, key preservation).

I'll add the seeded-keys alternative to the RFC's "Why not a general
grouping function?" section.

Thanks,
Ayoub

I wouldn't be disappointed to see array_partition() added to the language, but the longer I think about it, a well-designed array_group() function could provide the equivalent behavior as well as afford other than just 2 static groups.

It seems like the only relevant difference is the fact that array_partition() always returns an indexed array of two arrays without needing to push 2 empty arrays for padding. Theoretically, array_group() might not return any subarrays when there are no qualifying items to retain. Does array_group() need an optional 3rd parameter which declares an empty array for each nominated grouping key which can be nominated in a particular order? Food for thought.

Instead of potentially creating array_partition() and eventually array_group(), I feel any benefits of array_partition() should be baked into an array_group() function for greater utility in a unified function.

mickmackusa

Proposal for Discussion: Effect Declarations and Capability-Gated Process Execution in PHP

Mon, 26 Oct 2026 13:50:07 +0000

Hello David,

Thank you for taking the time to read the proposal and share your
questions. I appreciate the feedback, and I think these are important
points to clarify.

1. Effects for process execution

I agree that invoking native binaries should not be encouraged as a default
approach when an API or shared library is more appropriate. My intention is
not to promote process execution, but to make potentially dangerous
operations explicit and controllable.

The main motivation behind this idea is to explore whether PHP could
provide stronger protection against unintended or unauthorized operations,
including attacks such as PHP2Shell. If an attacker exploits a
vulnerability in an application, the impact could be reduced if the
affected execution context is not authorized to perform sensitive
operations.

One analogy I have in mind is the permission model used by mobile operating
systems. An application may request internet access, camera access, or
filesystem access, but the operating system determines which permissions it
actually receives. Some applications may have a permission while others do
not.

Similarly, a PHP application or execution context could be granted specific
capabilities, while sensitive operations would be denied when the required
authorization is absent. Process execution is simply one potential use
case, and perhaps a useful starting point because of its security
implications.

2. Parameterized effects and configurable values

I agree with your point about API domains and environment-specific
configuration. Hardcoding a hostname in an effect declaration would create
unnecessary coupling if the endpoint changes between environments or needs
to be updated.

I would not want effect declarations to replace configuration or require a
language-level versioning change whenever a string value changes.

Instead, parameterized effects could describe constraints or categories of
operations, with the actual values supplied through configuration or
checked against runtime policy. For example, an effect could indicate that
a function may perform network requests, while the permitted hosts are
determined by the application’s configuration and enforced at runtime.

The same distinction could apply to filesystem access: an effect could
declare that a function reads files, while a runtime policy determines
which paths are permitted.

I am open to whether parameterized effects should contain literal
constraints, reference named policies, or simply describe the operation
while leaving authorization to a separate mechanism.

3. Static analysis versus runtime enforcement

I agree that static analysis cannot reliably determine every operation in a
dynamic language such as PHP, particularly when behavior depends on runtime
input, dynamic calls, or native extensions. I do not expect PHPStan or
Psalm to replace runtime security enforcement.

However, I think static analysis could still provide value by identifying
operations that contradict declared effects.

For example, if a function declares that it only performs calculations, a
static analyzer could flag direct or indirect calls to known
filesystem-reading functions, such as glob() or file_get_contents(), where
those calls are identifiable. Similar checks could be applied to network
and process-execution APIs.

This would not be a complete security guarantee. Dynamic dispatch, indirect
calls, and native extensions would introduce limitations. Runtime
enforcement would therefore be necessary for security-sensitive operations,
with the PHP engine or another trusted runtime mechanism checking whether
the active execution context has the required authority.

Consider a function exposed through an HTTP endpoint whose responsibility
is only to perform a calculation. Ideally, that function should not be able
to make arbitrary API requests, read arbitrary files, or execute system
commands merely because PHP currently allows those operations. Its
permitted effects and runtime authority should reflect what it actually
needs to do.

The broader goal is to explore whether PHP could move towards a model where
potentially sensitive operations are both visible in code and constrained
by enforceable permissions, rather than relying exclusively on developers
to remember every possible attack path.

I realize this raises substantial questions around backward compatibility,
the existing extension ecosystem, and the boundary between language
semantics and runtime security. I do not have all the answers yet, and
feedback like yours is helpful in determining the right direction and scope.

Thank you again for engaging with the proposal.

Sincerely,
Arsan Gamal

Sent from Gmail

Hello Arsan. It sounds very interesting.

However I have some questions:

Use of effect for binaries: I'm not used to the idea of using PHP to
invoke a Binary. Most of the time it tries to invoke an API or a shared
library or something similar. Is it a good idea to encourage calling native
binaries? (I'm sure some people do it. But adding such as a green check of
"you can do it", seems a little of).

The use of effect for API call: It is interesting. But what if you want
to update an API endpoint/domain? You would have to manually change it in
the code. Is a SemVer-like (semantic versioning) change necessary for a
string data? As far a I know people get these value from an .env file or
something ? (The filesystem.read you gave seems more appropriate.

I'm not sure that any static analyser would be able to check it. Because
these kind of checks are to be done in runtime, right? Does PHPStan or
Psalm for instance do test in runtime? It seems that it would be a
responsibility for the PHP engine/runtime?

What do you think?

Kind regards,
David Maye

Hello PHP Internals,

I would like to propose an idea for discussion regarding the introduction
of effect declarations in PHP, with a particular focus on making function
behavior more explicit and improving the security and auditability of
sensitive operations.

Currently, PHP function signatures describe parameters and return values
but do not indicate which external operations a function may perform. A
function may execute operating-system commands, access the filesystem, or
make network requests through its implementation or dependencies without
these operations being visible in its signature.

I believe an effect system could help address this limitation by allowing
functions to declare the operations they may perform. These declarations
could support static analysis, contract checking, code auditing, and
potentially stronger security controls.
Proposed syntax

As an initial proposal, effects could be declared alongside a function's
return type:

function generateReport(string $input): string
effects [process.execute]
{
// Implementation
}

Effects could also accept parameters to describe the scope of an operation:

function generateReport(string $input): string
effects [
process.execute(
commands: ['/usr/bin/report-renderer']
)
]
{
// Implementation
}

In this example, the effect declaration indicates that the function may
execute a process, with the declared contract restricting the intended
executable to the report renderer.

The same concept could be extended to other operations:

function readConfiguration(): string
effects [
filesystem.read(
paths: ['/etc/myapp/config.json']
)
]
{
// Implementation
}

function fetchReport(string $url): string
effects [
network.request(
hosts: ['api.example.com']
)
]
{
// Implementation
}

These examples are illustrative and are not intended to prescribe the
final grammar. The syntax, supported effect types, parameter formats, and
enforcement rules would need to be discussed and evaluated.
Effect checking and security

I envision effects serving as explicit contracts describing the operations
a function may perform. A static analyzer or compiler could check whether
implementations and their dependencies respect these declarations, identify
undeclared effects, and make sensitive operations more visible during code
review.

Parameterized effects could provide additional information about the
intended scope of an operation. For example, a function declaring a
process-execution effect restricted to a particular executable could be
checked for attempts to execute other programs.

I would also like to explore how this proposal could complement a
capability-based security model. Effects and capabilities would have
separate responsibilities: effects would describe the operations and
constraints associated with a function, while capabilities would determine
which operations are authorized at runtime.

For example, an application could grant a request handler permission to
execute a specific binary with defined argument constraints and resource
limits. The runtime would enforce that permission when a process is
created, independently of the function's effect declaration.

This distinction is important because declaring an effect should not
automatically grant authority to perform the operation. Runtime enforcement
would remain necessary for security-sensitive operations, even if static
effect checking were available.
Scope and open questions

I recognize that PHP's dynamic features, backward-compatibility
requirements, and native extension ecosystem present significant design and
implementation challenges. Some questions that would need further
exploration include:

Whether effects should be explicitly declared, inferred, or support
both approaches.

How effects should propagate through function calls, closures, dynamic
calls, and third-party dependencies.

How parameterized effects should be represented and validated.

Whether effect contracts should be enforced by the PHP engine,
external static analysis tools, or a combination of both.

How effects could integrate with runtime capabilities and existing
APIs.

How strict enforcement could be introduced without breaking existing
PHP applications.

The proposal would not, by itself, prevent vulnerabilities within the PHP
engine or native extensions. Any runtime security guarantees would depend
on the coverage and correctness of the enforcement mechanisms.

I have started drafting an RFC exploring these ideas, using process
execution as an initial use case. I would welcome feedback on whether
effect declarations and parameterized effects would be a worthwhile
direction for PHP, whether the proposed syntax fits the language, and what
scope would be appropriate for an initial RFC.

If there is interest, I would be happy to share the draft and work on a
proof of concept.

Thank you for your time and consideration.

Respectfully yours,
Arsan Gamal
Senior Software Engineer

Proposal for Discussion: Effect Declarations and Capability-Gated Process Execution in PHP

Mon, 26 Oct 2026 13:20:03 +0000

[RFC] array_partition()

Mon, 26 Oct 2026 12:26:05 +0000

I wouldn't be disappointed to see array_partition() added to the language,
but the longer I think about it, a well-designed array_group() function
could provide the equivalent behavior as well as afford other than just 2
static groups.

It seems like the only relevant difference is the fact that
array_partition() always returns an indexed array of two arrays without
needing to push 2 empty arrays for padding. Theoretically, array_group()
might not return any subarrays when there are no qualifying items to
retain. Does array_group() need an optional 3rd parameter which declares
an empty array for each nominated grouping key which can be nominated in a
particular order? Food for thought.

Instead of potentially creating array_partition() and eventually
array_group(), I feel any benefits of array_partition() should be baked
into an array_group() function for greater utility in a unified function.

mickmackusa

What happens to newcomers' PRs in php-src — a year of data

Mon, 26 Oct 2026 08:07:49 +0000

I looked at a year of newcomers' work

125 PRs are inactive

The most friction I had as a newish contributor was what happens after you create a pull request, and nobody responds to it. I have quite some trouble getting my PRs reviewed.

I also dislike the asymmetry where a single poorly motivated objection can cause an author months of RFC paperwork.

Regards,

Sjoerd Langkemper

What happens to newcomers' PRs in php-src — a year of data

Sun, 25 Oct 2026 18:38:48 +0000

Hi all,

#24613 https://github.com/php/php-src/pull/24613 (the duplicate-PR
policy) got me wondering what actually happens to PRs
from people coming to php-src for the first time. I looked at a year of
newcomers' work, and the data seemed interesting enough to share.

Scope: every PR opened between 24 Oct 2025 and 24 Oct 2026 whose author
opened
their very first php-src PR within that window. That's 831 PRs from 219
people,
about a quarter of all PRs in the period.

Key observations:

Of 831 PRs, 418 were accepted, 157 closed without a merge, and the rest
have
no outcome yet.
More newcomers keep arriving: first-time contributors grew from 1–5 a week
early on to 5–12 by autumn, 219 over the year. PR volume followed, from
2–5 a
week to 30–70.
Of the 157 closed, a reason was stated in the discussion for 124. The
biggest
groups: the change isn't wanted (38), the author closed it themselves
(34),
duplicates (31). Most "no"s are about fit or process (out of scope, needs
an
RFC, wrong target branch), not code quality. PRs called outright wrong in
the
code are rare.
Newcomers write tests more often than the repo overall — 68% vs 52%.
PRs with AI-written descriptions (113, about 14%) are accepted noticeably
less
often: around 20% vs 55%.
143 of 219 newcomers opened exactly 1 PR, 76 more than one, but 47 of
them did
it in a single day. 362 of 831 PRs were opened by people who fired off a
pile
at once.
The top 10 authors opened 487 of 831 PRs (59%) and are accepted at 67%,
while
the other 209 authors sit at 27% (344 PRs).
One author opened 232 PRs with 84% acceptance — that's 28% of all
newcomer PRs
and 46% of the accepted ones; without him overall acceptance drops from
50%
to 37%.
Acceptance depends a lot on which PR it is for the author: the first PR
29%,
but after a first accepted one 66%. It's the first success that matters,
not
just continuing.
125 PRs are inactive (closed after silence, or open and idle for 50+
days).
Reaction speed tracks resolution: a first maintainer response within a
day →
median close ~20h, versus ~32 days when it takes over a week (Spearman
0.53).

Full write-up, charts and method:
https://artukrainskiy.github.io/posts/newcomer-prs-in-php-src/
Raw per-PR data:
https://docs.google.com/spreadsheets/d/185nNwTnj-E6FNjAYLzPZ7ly4QJzEP9iHoUbPgHrrnR4/edit?usp=sharing

If there's interest, I'm happy to dig deeper so the numbers are solid
enough to
draw conclusions from. I can also share the classification prompts and the
scripts if that's useful.

One idea I'd like to put up for consideration, and I'd like to know if it'd
be
welcome. A bot that, when a PR opens, checks the mechanical things — no
tests, a
weak or empty description, no benchmarks in a PR aimed at optimization, the
wrong
target branch, an obvious duplicate — and leaves the author a note right
away. It
wouldn't judge whether a change is wanted, and it wouldn't add review time.
Part
of this can be done "for free" without an LLM, and by my rough estimate
even a
first-pass LLM review could be cheap enough.

An instant note there could spare maintainers the trivial round-trips and
let
contributors fix things before anyone even looks. My study suggests a fast
response leads to a faster close, and with the number of newcomers trending
up
this would help offload maintainers, at least on first-pass reviews and
trivial
checks. Larger projects already do this.

Is it worth prototyping?

--
Best regards,
Artem Ukrainskiy

From mono-implementation risk to spec: Lessons from CVE-2026-109618/109619 and a path to K/Redex semantics[Idea]

Sun, 25 Oct 2026 17:12:26 +0000

PHP today has no formal specification. As the KPHP work
(Filaretti et al., ECOOP'14) notes, Zend is the de-facto
spec. That makes this class of bug hard to catch:
...
I am proposing we use this incident to start:

A) Formalize Zend bytecode and parser as a living spec
B) Reference executable semantics in two formal frameworks:

I think PHP is not starved for bugs. The bottleneck is bugfixes. As I
understand it the problems leading to these CVEs were already found by
an earlier security test, but the problem was coming up with a good
fix. I think creating a spec and a second implementation is not the
most efficient way to find and solve bugs.

Regards,

Sjoerd Langkemper

To be blunt, the way to address the bottlenecks on bug fixing is to badger PHP-using companies into becoming significant PHP Foundation sponsors. Or dedicating their own employees full time to PHP maintenance.

This is a money problem, just like most major OSS projects. It's nothing more complicated than that. A formal spec may have merit, but it has no relevance to the current situation.

--Larry Garfield

From mono-implementation risk to spec: Lessons from CVE-2026-109618/109619 and a path to K/Redex semantics[Idea]

Sun, 25 Oct 2026 15:32:42 +0000

PHP today has no formal specification. As the KPHP work
(Filaretti et al., ECOOP'14) notes, Zend is the de-facto
spec. That makes this class of bug hard to catch:
...
I am proposing we use this incident to start:

A) Formalize Zend bytecode and parser as a living spec
B) Reference executable semantics in two formal frameworks:

I think PHP is not starved for bugs. The bottleneck is bugfixes. As I understand it the problems leading to these CVEs were already found by an earlier security test, but the problem was coming up with a good fix. I think creating a spec and a second implementation is not the most efficient way to find and solve bugs.

Regards,

Sjoerd Langkemper

[RFC] array_partition()

Sun, 25 Oct 2026 13:38:55 +0000

Hi internals,

I'd like to start the discussion on a new RFC:

https://wiki.php.net/rfc/array_partition

It proposes a function that splits an array into the elements for which
a callback returns a truthy value and those for which it does not, in a
single pass:

function array_partition(array $array, callable $callback): array {}

[$adults, $minors] = array_partition($users, fn($u) => $u->age >= 18);

Keys are preserved, and the callback receives the value and the key,
following array_find(). The result is always a list of two arrays, with
the matching elements first, as in Ruby, Kotlin, Rust, Haskell and
Laravel's Collection::partition().

The RFC also covers the points raised in the karma request thread:
why it is a two-way split rather than a general grouping function, why
the result is not keyed by true/false, and the $callback parameter
name. It also discusses the previous userland uses of the name
array_partition() with an "N chunks" meaning.

The implementation is at https://github.com/php/php-src/pull/24568.

Thanks to Ilija for granting the karma, and to everyone who commented
on the earlier thread. I look forward to your feedback.

Ayoub

Proposal for Discussion: Effect Declarations and Capability-Gated Process Execution in PHP

Sun, 25 Oct 2026 13:38:09 +0000

Hello PHP Internals,

I would like to propose an idea for discussion regarding the introduction
of effect declarations in PHP, with a particular focus on making function
behavior more explicit and improving the security and auditability of
sensitive operations.

Currently, PHP function signatures describe parameters and return values
but do not indicate which external operations a function may perform. A
function may execute operating-system commands, access the filesystem, or
make network requests through its implementation or dependencies without
these operations being visible in its signature.

I believe an effect system could help address this limitation by allowing
functions to declare the operations they may perform. These declarations
could support static analysis, contract checking, code auditing, and
potentially stronger security controls.
Proposed syntax

As an initial proposal, effects could be declared alongside a function's
return type:

function generateReport(string $input): string
effects [process.execute]
{
// Implementation
}

Effects could also accept parameters to describe the scope of an operation:

function generateReport(string $input): string
effects [
process.execute(
commands: ['/usr/bin/report-renderer']
)
]
{
// Implementation
}

In this example, the effect declaration indicates that the function may
execute a process, with the declared contract restricting the intended
executable to the report renderer.

The same concept could be extended to other operations:

function readConfiguration(): string
effects [
filesystem.read(
paths: ['/etc/myapp/config.json']
)
]
{
// Implementation
}

function fetchReport(string $url): string
effects [
network.request(
hosts: ['api.example.com']
)
]
{
// Implementation
}

These examples are illustrative and are not intended to prescribe the final
grammar. The syntax, supported effect types, parameter formats, and
enforcement rules would need to be discussed and evaluated.
Effect checking and security

I envision effects serving as explicit contracts describing the operations
a function may perform. A static analyzer or compiler could check whether
implementations and their dependencies respect these declarations, identify
undeclared effects, and make sensitive operations more visible during code
review.

Parameterized effects could provide additional information about the
intended scope of an operation. For example, a function declaring a
process-execution effect restricted to a particular executable could be
checked for attempts to execute other programs.

I would also like to explore how this proposal could complement a
capability-based security model. Effects and capabilities would have
separate responsibilities: effects would describe the operations and
constraints associated with a function, while capabilities would determine
which operations are authorized at runtime.

For example, an application could grant a request handler permission to
execute a specific binary with defined argument constraints and resource
limits. The runtime would enforce that permission when a process is
created, independently of the function's effect declaration.

This distinction is important because declaring an effect should not
automatically grant authority to perform the operation. Runtime enforcement
would remain necessary for security-sensitive operations, even if static
effect checking were available.
Scope and open questions

I recognize that PHP's dynamic features, backward-compatibility
requirements, and native extension ecosystem present significant design and
implementation challenges. Some questions that would need further
exploration include:

Whether effects should be explicitly declared, inferred, or support both
approaches.

How effects should propagate through function calls, closures, dynamic
calls, and third-party dependencies.

How parameterized effects should be represented and validated.

Whether effect contracts should be enforced by the PHP engine, external
static analysis tools, or a combination of both.

How effects could integrate with runtime capabilities and existing APIs.

How strict enforcement could be introduced without breaking existing PHP
applications.

The proposal would not, by itself, prevent vulnerabilities within the PHP
engine or native extensions. Any runtime security guarantees would depend
on the coverage and correctness of the enforcement mechanisms.

I have started drafting an RFC exploring these ideas, using process
execution as an initial use case. I would welcome feedback on whether
effect declarations and parameterized effects would be a worthwhile
direction for PHP, whether the proposed syntax fits the language, and what
scope would be appropriate for an initial RFC.

If there is interest, I would be happy to share the draft and work on a
proof of concept.

Thank you for your time and consideration.

Respectfully yours,
Arsan Gamal
Senior Software Engineer

From mono-implementation risk to spec: Lessons from CVE-2026-109618/109619 and a path to K/Redex semantics[Idea]

Sun, 25 Oct 2026 12:41:47 +0000

Hi Brian,

The vulnerable pattern — count-before-alloc + OOM bailout —
could have been modeled and fuzzed if the invariants of
HashTable and ZendMM were specified outside of C.

It seems to be that the memory manager and internal structures are exactly the part that would vary between implementations. PHPNG (the basis of 7.0) heavily rewrote exactly those parts; an implementation on top of another runtime like .net or JVM would naturally make use of their underlying memory management; a rewrite in fully-checked Rust or Zig would use different mechanisms than one in C. A meaningful spec would cover all of those, asserting that the behaviour observed from the outside matches.

I can't see how a specification would have helped here, any more than the HTML Specification helps prevent memory management bugs in browser implementations.

.NET is a useful counter-example, not because "Microsoft
exists", but because it chose to keep alternative runtimes.

Microsoft employs about 200_000 people. If 0.01% of those are paid to work full time on .NET, that's still twice as many as have ever been paid to work full time on PHP.

If someone came along offering to create a competing implementation of PHP, I would beg them to instead spend the effort improving the one we already have.

Regards,

Rowan Tommins
[IMSoP]

[RFC Idea] Formalization moratorium after PHP2Shell (CVE-2026-109618/109619): independent implementations in Rocq/Agda/K/Redex

Sun, 25 Oct 2026 08:30:17 +0000

Hi internals,

Summary:
In October 2026 two critical runtime vulnerabilities, CVE-2026-109618 and
CVE-2026-109619 (PHP2Shell, CVSS 9.2, fixed in 8.2.35 / 8.3.36 / 8.4.27 /
8.5.12 on Oct 21), were found in the Zend Memory Manager and HashTable /
session upload progress handling. Not in ext/dom, ext/curl, or any
application — in the allocator and stale request globals. This affects
essentially every SAPI (FPM, mod_php, CGI, FrankenPHP).

Motivation - mono-implementation brittleness:
PHP is still defined by a single implementation. Efforts like php-langspec
and KPHP were abandoned in the PHP 7 era. Today PHP_CodeSniffer,
PHP-CS-Fixer, and PHP-Parser each maintain their own partial parsers,
PeachPie must add workarounds for Laravel, and HHVM abandoned PHP
compatibility in 2019 to become Hack. Without a second implementation and a
formal spec, we have no way to catch this class of bug early.

Cost of cosmetic deprecations:
We have just deprecated non-canonical casts: (integer) -> (int), (boolean)
-> (bool), (double) -> (float), (binary) -> (string). They are functionally
identical. While well-intentioned for consistency, each such deprecation
forces churn across tooling and user code. That time is not spent on
reinforcing the base — exactly what PHP2Shell shows we need.

Proposal:

Impose an immediate embargo on all new features and all cosmetic
deprecations until the mono-implementation situation is rectified. Not
adding a feature cannot break apps. Not deprecating (integer) cannot break
apps. A corrupt allocator can.
Complete the spec attempt left behind by
【entity-Facebook¦canonical_name=Facebook】 by reading php-src with AI
assistance.
Do not do the old ArtCraft-style clone-in-Rust-first approach. Since
this class of bug was found with AI, and AI can now write directly in
formalized languages, I propose we implement directly in formal frameworks:
a) Extract and standardize the two ground truths: Zend Engine bytecode
and the formal parser.
b) Build 4 independent implementations directly: two operational
semantics in K Semantic Framework and Racket PLT Redex, and two mechanized
definitions in Rocq and Agda.
c) Build a PyPy/Roslyn-style compiler from PHP to bytecode/JS from those
definitions to bootstrap semantics.
d) Cross-test all implementations against php-src tests AND WordPress,
MediaWiki, Laravel, and other major codebases.
e) Demonstrate bootstrapping by using the new implementations to compile
the bootstrapped runtime with itself.

This gives us what other mature runtimes have: .NET has CoreCLR and still
keeps a Mono option to stress-test additions; Python has PyPy, Cython,
Brython. PHP needs the same.

I am not arguing for permanent stasis, only for sequencing: formalize and
diversify first, then resume features. That is how we prevent irrelevance
for greenfield projects.

Thanks,
Brian

RFC karma request: array_partition()

Sun, 25 Oct 2026 00:36:43 +0000

Hi Ayoub

I'd like to request RFC karma on the wiki to propose a new function,
array_partition(). My wiki username is: ayoubezzini

RFC karma was granted, good luck!

Ilija

RFC karma request

Sun, 25 Oct 2026 00:35:47 +0000

Hi Frode

I would like to request RFC karma for my wiki account, frodeborli.

I intend to publish an RFC called "Scope", introducing a notion of
logical operation identity to PHP, independent of fibers and
generators, but preserved across their execution.

Sorry that I missed your request, it's been pretty stressful last few
weeks.

RFC karma was granted, good luck!

Ilija

From mono-implementation risk to spec: Lessons from CVE-2026-109618/109619 and a path to K/Redex semantics[Idea]

Sat, 24 Oct 2026 20:59:35 +0000

Hi internals,

I want to raise a broader process question following the
emergency releases on Oct 21 for CVE-2026-109618 and
CVE-2026-109619.

I had noted privately back in 2020 that given the lack of a
formal spec and single-implementation status, I expected the
next critical vulnerability to be in the language runtime and
execution layer itself — not in ext/dom, ext/curl, ext/gd,
or HTTP handling — but in memory allocation and hashtable
management. The October disclosures matched that pattern,
which is why I'm writing now.

What happened:

CVE-2026-109618 (CVSS 9.2, "rawkey"): in Zend Engine's
HashTable implementation, _zend_hash_str_add_or_update_i
increments the entry count before allocating the new
key. If that allocation exceeds memory_limit, Zend calls
zend_bailout() via longjmp, abandoning the request with a
counted-but-uninitialized bucket. Request shutdown then
treats stale memory as a valid zend_string. Requires a
POST with a large field name (>1MB).
CVE-2026-109619 (CVSS 9.2, "stale global state"): in
session.upload_progress, request-owned state is retained
after free and reused by a later request on the same
worker. Small body (~450 bytes).

Fixed in 8.2.35, 8.3.36, 8.4.27, 8.5.12. The advisories note
the underlying code goes back to PHP 5.4. Exploitation is
below the application layer — mod_php was confirmed
exploitable before any application code runs.

This is not a bug in an extension. It is a bug in ZendMM,
zend_hash, and request lifecycle — the core runtime.

Why this matters beyond the patch:

PHP today has no formal specification. As the KPHP work
(Filaretti et al., ECOOP'14) notes, Zend is the de-facto
spec. That makes this class of bug hard to catch:

No alternative implementation to disagree with Zend.
Python has CPython/PyPy/Cython, JavaScript has
V8/SpiderMonkey/JSC, .NET has CoreCLR/Mono. PHP had
HHVM and has PeachPie (.NET), but without a stable
bytecode/parser spec, compatibility diverged — HHVM
dropped PHP compat in 2019 to become Hack, PeachPie
needs workarounds for Laravel. We are back to one
reference implementation.
No stable bytecode spec for independent tooling. The
vulnerable pattern — count-before-alloc + OOM bailout —
could have been modeled and fuzzed if the invariants of
HashTable and ZendMM were specified outside of C.

The broader ecosystem point:

.NET is a useful counter-example, not because "Microsoft
exists", but because it chose to keep alternative runtimes.
.NET Framework was proprietary and Windows-only. Mono (2001)
was the independent implementation that pushed it open.
Microsoft open-sourced .NET Core in 2014, it became truly
cross-platform (ASP.NET Core on Linux/macOS/Windows), and
today .NET intentionally ships both CoreCLR and Mono runtimes
to stress-test feature additions. The .NET Foundation model
is similar to what the PHP Foundation has been building
since 2021.

PHP's trajectory was the opposite: we lost the second
implementation. The cost is not that PHP becomes "irrelevant"
overnight — it powers a huge share of the web — but that
trust erosion makes teams choose Node/Python/Go for new
systems while keeping PHP for existing WordPress installs.
Long-lived runtime RCEs accelerate that.

Why I think a spec effort is more tractable now:

The CVE-2026-109618 lead was flagged by automated audit
tooling (Ryan Austin's agent flagged the count-before-alloc
in _zend_hash_str_add_or_update_i). AI-assisted auditing of
the Zend heap path is now practical.

Similarly, recent AI-assisted re-implementations of legacy
binary formats and apps from scratch (e.g., ArtCraft's work
cloning apps and data formats in Rust with no legacy code)
show that re-implementing a complex legacy format from a
reference implementation + test suite is more feasible today
than when KPHP was manually written in 2014.

We can leverage that to bootstrap PHP semantics.

Proposal for discussion, not an embargo:

I am not proposing freezing features or cosmetic deprecations.
I am proposing we use this incident to start:

A) Formalize Zend bytecode and parser as a living spec
extracted from php-src (8.4/8.5 baseline), including
OOM/bailout semantics.

B) Reference executable semantics in two formal frameworks:

K Framework (building on KPHP)
PLT Redex / Racket, to cross-check the model
Both should model HashTable invariants, ZendMM alloc
failure, and request lifecycle.

C) PyPy/Roslyn-style bootstrapping: a compiler from PHP to
Zend bytecode and to other targets (e.g., JS) to validate
semantics, plus self-hosting tests (compile the bootstrap
compiler with itself).

D) Conformance via differential testing: run phpt plus
WordPress, MediaWiki, Laravel, Symfony against any
alternative runtime, not just phpt.

If there is interest, I can draft a short RFC outline for
(A) + (B) as a first step, and talk to the PHP Foundation
(contact@thephp.foundation) about whether this is fundable
as Foundation work.

Thanks for reading this long mail,

Brian

[RFC] Io\Terminal

Sat, 24 Oct 2026 17:12:25 +0000

Hi Sjoerd,

I've pushed fixes for the issues you pointed out, along with regression tests.

Zero-timeout reads now handle already-available escape sequences
without waiting, and getSize() no longer suppresses a pending resize
notification.

While testing, I also found that incomplete UTF-8 at EOF could cause
readKey() to keep returning null. It now throws TerminalException on
EOF, while genuine timeouts still preserve the partial bytes.

https://github.com/php/php-src/pull/23941

Thanks again for the careful review.

Regards,
Pratik

On Fri, 23 Oct 2026 16:44:51 -0700, Pratik Bhujel
prateekbhujelpb@gmail.com wrote:

Hi Sjoerd,

Thanks for taking a look.
Perhaps it would be desirable to distinguish between the user cancelling, and a genuine error, and perhaps also EOF; for example with subclasses of TerminalException.
Yes, I see the use case. An application may handle a cancelled password prompt quietly but report an I/O failure. Currently they all throw TerminalException, and the messages are not stable identifiers. Separate subclasses would allow that distinction while keeping TerminalException as the common catch. I would like to settle this before the vote.
Is this sufficiently long, even when used over SSH or such? Is this configurable in readSecret as well?
The 25 ms starts after Escape arrives, so it is not a limit on the SSH round trip. Delayed fragments can still exceed it. readKey() lets you increase sequenceTimeout, within the overall timeout.

readSecret() currently uses a fixed 25 ms wait in its byte-stream escape handling. It is not separately configurable, and increasing the overall timeout does not increase that wait. That is a limitation worth addressing. Native Windows console input uses input records, so this escape-sequence timing does not apply there.
If I resize the terminal twice, do I get two Key::Resize? getSize() seems to update the stored size of the terminal. Do I still get a Key::Resize after I call getSize()?
Not necessarily two. On POSIX, resize notifications can be coalesced, and changes between reads can be detected by comparing dimensions.

You are right about getSize(). It updates the same cached dimensions, so calling it first can hide a change from that comparison. Windows can still have queued resize records. I think getSize() should query the size without acknowledging a pending notification. That needs fixing and documenting. Resize should mean "check the current size", rather than promise a count of every resize.
This would not work with escape sequences, right? Or does it work correctly if the key is already buffered?
Reading the current byte-stream decoder, the zero deadline makes it return Escape before checking the remaining bytes, even if the whole sequence is buffered. The focused zero-timeout test covers a lone Escape.

Zero should prevent waiting while still allowing a complete available sequence to be decoded. That needs a focused regression test and a fix.

I’ll follow up with the test results and changes. These findings are from checking the code; I haven’t run the new reproducers yet.

Regards,
Pratik

[RFC] Paren-less access to scalar extension methods ('a,b'->arr as sugar for 'a,b'->arr())

Sat, 24 Oct 2026 13:26:06 +0000

Hi,

This follows up on the Extension Methods / Scalar Extension Methods RFCs (currently in draft). I'd like to propose allowing extension methods on scalar values to be invoked through property-fetch syntax, with the parentheses omitted.

Hi,

I'd be a strong -1 on this. It seems like an entirely arbitrary rule, to save two characters per call, making the language less consistent, and closing off syntax that might be useful for something else in future.

It also seems odd to propose it now, as an extension to something that doesn't even exist yet. Surely there are much more "critical path" details of extension and scalar methods that we need to iron out before thinking about such extra sugar?

Regards,

Rowan Tommins
[IMSoP]

RFC karma request: array_partition()

Sat, 24 Oct 2026 13:18:40 +0000

Hi Morgan,

Thanks for the support!

my partition functions also map passes and rejects to true and false
respectively (so the result is a mapping from booleans to array values).

[true => $passed, false => $rejected] = array_partition(...);

I looked at this, and the catch is that boolean array keys are cast to
integers, so true => 1 and false => 0. A boolean-keyed result would
therefore have to put the rejected elements at index 0, and then
positional destructuring silently gives the opposite of what it reads:

[$adults, $minors] = array_partition($users, fn($u) => $u->age >= 18);
// with a bool-keyed result, $adults would hold the minors

Whichever layout is chosen, one of the two idioms ends up swapped. I'd
rather keep "matching first" at index 0, since that's what Ruby, Kotlin,
Rust, Haskell and Laravel all return, and it makes the plain
[$matching, $rest] destructuring work. I'll document the pitfall
explicitly in the RFC, with your example, so nobody reaches for
[true => ..., false => ...] expecting it to work.

I would also prefer the callback parameter to be named $predicate, to
emphasise that it is supposed to return a boolean.

I agree it's more descriptive in isolation. But every other array
function taking a callback names it $callback, including array_filter()
and the recent array_find(), array_find_key(), array_any() and
array_all(), which are also predicates. With named arguments I think
it's more valuable that callback: works the same way across the whole
family, so I'd prefer to keep $callback for consistency. I'll mention
it in the RFC as a considered alternative.

Thanks,
Ayoub

Hi Ayoub,

It feels unintuitive that true callback outcomes map to the 0 key
and false outcomes map to 1.
I'm also in support, and this would have been my only observation: my
partition functions also map passes and rejects to true and false
respectively (so the result is a mapping from booleans to array values).

If that mapping were retained, it could be documented in code as

[true => $passed, false => $rejected] = array_partition(...);

or

$adult_tested = array_partition(...);

$adults = $adult_tested[true];
$minors = $adult_tested[false];

I would also prefer the callback parameter to be named $predicate, to
emphasise that it is supposed to return a boolean. $callback doesn't
convey as much about what it's for - the same name is used, for example,
in usort(), where it's a comparator. It didn't matter until named
parameters became a thing.

[RFC] Paren-less access to scalar extension methods ('a,b'->arr as sugar for 'a,b'->arr())

Sat, 24 Oct 2026 09:33:53 +0000

Hi,

This follows up on the Extension Methods / Scalar Extension Methods RFCs (currently in draft). I'd like to propose allowing extension methods on scalar values to be invoked through property-fetch syntax, with the parentheses omitted.

Proposal: when a property read on a scalar fails, fall back to the extension method registry and invoke the method with its default arguments. ->name becomes sugar for ->name().

extension string $s {
public function arr(string $separator = ','): array {
return explode($separator, $s);
}
}

'a,b'->arr; // ['a', 'b'] <- new
'a,b'->arr(); // ['a', 'b'] <- already works
'a|b'->arr('|'); // ['a', 'b'] <- already works

Only methods callable with zero arguments would be eligible. 'abc'->needsArg would throw ArgumentCountError. Unknown names keep today's behavior.

Why this is cheap here: the main use case for scalar extension methods is derived values (length, upper, slug, toArray), which read like properties. And first-class callables are already disabled for scalar receivers (a by-value receiver cannot be bound into a Closure), so $s->arr cannot be interpreted as "return a Closure" - the only remaining meaning is "call it and return the value". That removes the usual ambiguity that makes this expensive in C#.

Scope: scalar receivers only (string, int, float, bool, array). Object receivers are excluded on purpose: a missing property on an object is usually a typo, and turning that warning into a successful call would weaken a useful diagnostic. Scalars have no property table today, so nothing is shadowed.

Backward compatibility: no parser change; ->name already compiles to ZEND_FETCH_OBJ_R. Today the affected expressions always emit "Warning: Attempt to read property "x" on string" and evaluate to null, which no correct code can rely on. Verified against a local build of hollyschilling/php-src@extension-methods-scalars (5e5112f):

'aaa'->length; // Warning: Attempt to read property "length" on string -> NULL
'a,b'->arr; // Warning: Attempt to read property "arr" on string -> NULL

These two lines are exactly what the proposal would change.

Open questions I'd like the list's input on:

A. When a method has a required parameter, throw ArgumentCountError (my preference; a silent null would be indistinguishable from a typo), or fall back to the existing warning?

B. Should isset() / ?? consult the registry, or stay untouched for v1?

C. Is excluding object receivers the right call, or is the resulting inconsistency ($str->upper works, $obj->upper does not) worse than losing the typo diagnostic on objects?

Happy to prototype against the extension-methods-scalars branch once (A) is settled.

Thanks,
h4acda

497161114
h4acda@qq.com

[RFC] Paren-less access to scalar extension methods ('a,b'->arr as sugar for 'a,b'->arr())

Sat, 24 Oct 2026 09:26:17 +0000

Hi,

Proposal: when a property read on a scalar fails, fall back to the extension method registry and invoke the method with its default arguments. ->name becomes sugar for ->name().

Only methods callable with zero arguments would be eligible. 'abc'->needsArg would throw ArgumentCountError. Unknown names keep today's behavior.

These two lines are exactly what the proposal would change.

Open questions I'd like the list's input on:

A. When a method has a required parameter, throw ArgumentCountError (my preference; a silent null would be indistinguishable from a typo), or fall back to the existing warning?

B. Should isset() / ?? consult the registry, or stay untouched for v1?

C. Is excluding object receivers the right call, or is the resulting inconsistency ($str->upper works, $obj->upper does not) worse than losing the typo diagnostic on objects?

Happy to prototype against the extension-methods-scalars branch once (A) is settled.

Thanks, <H4acda>

497161114
h4acda@qq.com

RFC karma request: array_partition()

Sat, 24 Oct 2026 04:46:28 +0000

Hi Ayoub,

It feels unintuitive that true callback outcomes map to the 0 key
and false outcomes map to 1.
I'm also in support, and this would have been my only observation: my
partition functions also map passes and rejects to true and false
respectively (so the result is a mapping from booleans to array values).

If that mapping were retained, it could be documented in code as

[true => $passed, false => $rejected] = array_partition(...);

$adult_tested = array_partition(...);

$adults = $adult_tested[true];
$minors = $adult_tested[false];

I would also prefer the callback parameter to be named $predicate, to
emphasise that it is supposed to return a boolean. $callback doesn't
convey as much about what it's for - the same name is used, for example,
in usort(), where it's a comparator. It didn't matter until named
parameters became a thing.

RFC karma request: array_partition()

Sat, 24 Oct 2026 00:19:33 +0000

Hi,

Thanks for the support and the detailed feedback!

Semantically, the function name affords an indefinite number of
groups/partitions.
[...]

Was strictly partitioning into only two parts a deliberate intention
specific to the term "partition"?

Yes, it was deliberate. In the languages and libraries PHP developers
are most likely to know, "partition" means a split by a boolean
predicate into exactly two parts: Ruby's Enumerable#partition, Kotlin's
partition, Rust's Iterator::partition, Haskell's Data.List.partition and
Laravel's Collection::partition. Each of them also ships grouping as a
separate function (group_by, groupBy, ...). I'd like PHP to follow the
same split, so that array_partition() does what people coming from
those ecosystems expect.

I want to be able to make unlimited groups keyed by the callback's
return value

That's a useful function too, but I think it's a different one. There
is an existing draft RFC for exactly that, array_group() by Boro
Sitnikovski (https://wiki.php.net/rfc/array_group, 2023), which never
went to a vote. I'd be happy to see it revived, and the two would
complement each other.

Using a general grouping function for the two-way case is also less
convenient: the bucket keys come from the callback's return value, and
a bucket is missing entirely when nothing falls into it. You'd write:

$groups = array_group($users, fn($u) => $u->age >= 18 ? 'adult' : 'minor');
$adults = $groups['adult'] ?? [];
$minors = $groups['minor'] ?? [];

whereas array_partition() always returns both parts, so destructuring
always works:

[$adults, $minors] = array_partition($users, fn($u) => $u->age >= 18);

It feels unintuitive that true callback outcomes map to the 0 key
and false outcomes map to 1.

The result is meant to be read as a pair rather than a map from boolean
to bucket, and "matching first" is the order used by all of the
functions above. With destructuring, the names carry the meaning:
[$matching, $rest].

The callback should have access to the arrays keys and values.

Agreed, and this is already done: following review on the PR, the
callback now receives ($value, $key), like array_find() and friends,
and the $mode parameter is gone:

function array_partition(array $array, callable $callback): array

https://github.com/php/php-src/pull/24568

I'll cover the naming and the relationship to array_group() in the RFC.

Thanks,
Ayoub

Hi Ayoub,

I am in support of array_partition() being added to the language in some way. Here is my feedback:

Semantically, the function name affords an indefinite number of groups/partitions. I have had many use cases where more than two partitions are desired.

It feels unintuitive that true callback outcomes map to the 0 key and false outcomes map to 1.

I want to be able to make unlimited groups keyed by the callback's return value (so long as the return value is a string or an int).
$ageGrouped = array_partition($users, fn($u) => $u->age ?? -1);
$byFirstByte = array_partition($words, fn($word) => substr($word, 0, 1));

The callback should have access to the arrays keys and values.
$modulusGrouped = array_partition($rows, fn($row, $i) => $i % 7);

Allowing your original intention of an indexed array with true outcomes first is still afforded by tweaking the evaluation or merely negating the boolean outcomes with !(expression).

Was strictly partitioning into only two parts a deliberate intention specific to the the term "partition"? I mean, did you deliberately choose to not name the function array_group()/array_batch() which might align with my behavioral deviation?

Good luck with the RFC.

mickmackusa

[RFC] Io\Terminal

Fri, 23 Oct 2026 23:44:51 +0000

Hi Sjoerd,

Thanks for taking a look.

Perhaps it would be desirable to distinguish between the user cancelling,
and a genuine error, and perhaps also EOF; for example with subclasses of
TerminalException.

Yes, I see the use case. An application may handle a cancelled password
prompt quietly but report an I/O failure. Currently they all throw
TerminalException, and the messages are not stable identifiers. Separate
subclasses would allow that distinction while keeping TerminalException as
the common catch. I would like to settle this before the vote.

Is this sufficiently long, even when used over SSH or such? Is this
configurable in readSecret as well?

The 25 ms starts after Escape arrives, so it is not a limit on the SSH
round trip. Delayed fragments can still exceed it. readKey() lets you
increase sequenceTimeout, within the overall timeout.

readSecret() currently uses a fixed 25 ms wait in its byte-stream escape
handling. It is not separately configurable, and increasing the overall
timeout does not increase that wait. That is a limitation worth addressing.
Native Windows console input uses input records, so this escape-sequence
timing does not apply there.

If I resize the terminal twice, do I get two Key::Resize? getSize() seems
to update the stored size of the terminal. Do I still get a Key::Resize
after I call getSize()?

Not necessarily two. On POSIX, resize notifications can be coalesced, and
changes between reads can be detected by comparing dimensions.

You are right about getSize(). It updates the same cached dimensions, so
calling it first can hide a change from that comparison. Windows can still
have queued resize records. I think getSize() should query the size without
acknowledging a pending notification. That needs fixing and documenting.
Resize should mean "check the current size", rather than promise a count of
every resize.

This would not work with escape sequences, right? Or does it work correctly
if the key is already buffered?

Reading the current byte-stream decoder, the zero deadline makes it return
Escape before checking the remaining bytes, even if the whole sequence is
buffered. The focused zero-timeout test covers a lone Escape.

Zero should prevent waiting while still allowing a complete available
sequence to be decoded. That needs a focused regression test and a fix.

I’ll follow up with the test results and changes. These findings are from
checking the code; I haven’t run the new reproducers yet.

Regards,
Pratik

RFC karma request: array_partition()

Fri, 23 Oct 2026 23:16:27 +0000

Hi Ayoub,

I am in support of array_partition() being added to the language in some
way. Here is my feedback:

Semantically, the function name affords an indefinite number of
groups/partitions. I have had many use cases where more than two partitions
are desired.
It feels unintuitive that true callback outcomes map to the 0 key and
false outcomes map to 1.
I want to be able to make unlimited groups keyed by the callback's return
value (so long as the return value is a string or an int).
$ageGrouped = array_partition($users, fn($u) => $u->age ?? -1);
$byFirstByte = array_partition($words, fn($word) => substr($word, 0, 1));
The callback should have access to the arrays keys and values.
$modulusGrouped = array_partition($rows, fn($row, $i) => $i % 7);
Allowing your original intention of an indexed array with true outcomes
first is still afforded by tweaking the evaluation or merely negating the
boolean outcomes with !(expression).
Was strictly partitioning into only two parts a deliberate intention
specific to the the term "partition"? I mean, did you deliberately choose
to not name the function array_group()/array_batch() which might align
with my behavioral deviation?

Good luck with the RFC.

mickmackusa

[IDEA] Native async/await syntax on top of Fibers

Fri, 23 Oct 2026 20:37:36 +0000

Hi internals,

I'd like to gauge interest in adding native async/await syntax to PHP,
built on top of the Fiber implementation we've had since 8.1.

Fibers made it possible to write concurrent code without "function
colouring", but in practice everyone still picks a userland library
(Amp, ReactPHP, Revolt) together with its own Promise/Future type, and
the code doesn't say directly what it means. The idea is to give the
engine a small, standard vocabulary for this:

async function fetch(string $name, float $secs): string {
    await Async\delay($secs);
    return "$name done";
}

$a = fetch("a", 0.2);   // starts right away, returns Async\Future
$b = fetch("b", 0.2);
echo await $a, await $b; // ~0.2s total, not 0.4s

Proposed semantics, in short:

async can be applied to functions, methods, closures and arrow
functions. Calling one runs its body in a new Fiber and returns an
Async\Future. The task starts eagerly and runs until it awaits a
Future that isn't complete yet.
await <expr> inside a task suspends that task. Outside a task (at
the top level, or in a plain Fiber) it drives a small scheduler until
the Future completes. It returns the value or rethrows the exception.
async is a contextual keyword: it is only a keyword when followed
by function or fn, so existing userland async() functions keep
working. await would become a reserved keyword, though it remains
usable as a method, constant or property name.
Tasks still pending at shutdown are destroyed the same way suspended
Fibers are, so their finally blocks run. Deadlocks throw an Error
instead of hanging.
A minimal runtime API: final class Async\Future, Async\async(),
Async\wait() (the function form of await), Async\delay() and
Async\suspend().

I have a working prototype. Both constructs are desugared in the
parser into calls to the runtime functions, so there are no new opcodes
and no VM changes:

https://github.com/php/php-src/pull/24623

It comes with tests and passes the existing test suite on a debug
build (macOS arm64, NTS). I haven't tried it on Windows or ZTS yet.

Questions I'd especially like feedback on:

Is reserving await an acceptable BC break? Unqualified functions
named await() would break; namespaced calls such as
Amp\Future\await() would not.
How should this relate to the True Async RFC? Should syntax like
this be layered on top of that work rather than proposed separately?
What should I/O integration look like? The prototype only supports
timers and cooperative yielding. Real-world usefulness depends on
an event-loop or reactor story for streams and sockets.
Known rough edges in the desugaring approach: func_get_args() inside
an async body returns [], stack traces show an extra {closure} frame,
and reflection reports the return type as Async\Future. Are these
acceptable, or is a dedicated engine-level implementation preferred?

If there is interest, I'm happy to turn this into a proper RFC.

Thanks,
Abbas Al-Khateeb

[RFC] Io\Terminal

Fri, 23 Oct 2026 20:26:19 +0000

I would like to formally propose the Io\Terminal API for PHP 8.7:

https://wiki.php.net/rfc/io_terminal

Thank you. Nice work.

EOF before submission, cancellation, and operational failures throw TerminalException.

Perhaps it would be desirable to distinguish between the user cancelling, and a genuine error, and perhaps also EOF; for example with subclasses of TerminalException.

The default for a blocking read is 25 milliseconds.

Is this sufficiently long, even when used over SSH or such? Is this configurable in readSecret as well?

A resize is returned as Key::Resize.

If I resize the terminal twice, do I get two Key::Resize? getSize() seems to update the stored size of the terminal. Do I still get a Key::Resize after I call getSize()?

$timeout sets the overall timeout: zero: make a non-blocking attempt

This would not work with escape sequences, right? Or does it work correctly if the key is already buffered?

Regards,

Sjoerd Langkemper

[Proposal] Clarifying the distinction between "PHP the Language" and "PHP the Software" on php.net

Fri, 23 Oct 2026 19:49:46 +0000

Hi everyone,

I would like to propose a small but important improvement regarding how PHP is described on the official php.net website and documentation.

Currently, many sections of the website simply use the term "PHP" without clearly distinguishing between "PHP as a programming language (the specification/syntax)" and "PHP as a software application (the official runtime environment/interpreter)".

This ambiguity causes significant confusion, particularly when users read about licensing. For example, statements implying that "PHP is available under the PHP License v4 / Modified BSD" can lead users—and corporate legal departments—to mistakenly believe that the license imposes restrictions or source-code disclosure requirements on the code they write in the PHP language itself.

To prevent this confusion, I propose that we update the official website and documentation to be more precise:

Use "PHP language" when referring to the syntax and coding rules.
Use "PHP software" or "PHP engine" when referring to the official runtime and its distribution license.

A clearer distinction would greatly help newcomers, developers, and legal teams understand that the permissive license applies strictly to the runtime engine and does not restrict their proprietary user code.

I would love to hear your thoughts on this.

Best regards,
The_PHP_Distinction

PHP 8.4.27 configure writes to read-only source tree but exits successfully

Fri, 23 Oct 2026 09:51:56 +0000

Kangwa Mukonda mukondakangwa1@gmail.com
11:44 AM (5 minutes ago)

to internals
Hello PHP internals,

I found a reproducible out-of-tree build-system issue in the signed PHP
8.4.27 release. I am using the internals list because bugs.php.net no
longer accepts reports and GitHub is unavailable in this environment.

Summary

When configure is run out of tree with the authenticated PHP source mounted
read-only, it attempts to create main/php_config.h.in.tmp inside the source
tree. The write fails with "Read-only file system", but configure
continues, creates the build Makefile, prints its success banner, and exits
with status 0.

Source

PHP 8.4.27 official tar.xz
SHA-256: dcf93923b0e38e0d5252b25b796520b5a47761a08b3488b6d0b5d1115764d3f0
Signature verified with PHP 8.4 release-manager key
9D7F99A0CB8F05C8A6958D6256A97AF7600A39A6.
The archive also matched Debian's independently signed php8.4
8.4.27-1~deb13u1 source byte-for-byte.

Environment

Kali rolling, x86_64
Linux 7.1.5+kali-amd64
GCC 15.3.0
GNU Make 4.4.1
Bubblewrap with a new network namespace; system and source trees read-only;
out-of-tree build directory writable.

Minimal reproduction

Extract php-8.4.27.tar.xz.
Create a separate writable build directory.
Make or mount the source tree read-only.
From the build directory run:

/path/to/php-8.4.27/configure --disable-all --enable-cli --disable-cgi
--disable-phpdbg --without-pear

Observed result

configure exit status: 0
Makefile created: yes
success banner printed: yes
read-only write failure count: 1

Relevant output:

configure: creating Makefile
configure: patching main/php_config.h.in
/path/to/php-8.4.27/configure: line 93943:
/path/to/php-8.4.27/main/php_config.h.in.tmp: Read-only file system
Thank you for using PHP.

Expected result

For a supported out-of-tree configuration, configure should not modify the
source tree. If modification is unavoidable, the failed write should be
fatal and configure should return a nonzero status instead of reporting
success.

Additional result

The generated build subsequently compiled successfully, so this report
concerns the unexpected source-tree write and swallowed failure rather than
a compilation failure.

Evidence

Full configure log SHA-256:
860f4189fb5c1b9b3a3aae43ff8ad498cbab6bbd4582d7c9e6a40beb71fe11f5

No exploit was developed or executed. I can provide the complete configure
log and reproduction receipt if useful.

Regards,
Mukonda Kangwa
Email: mukondakangwa1@gmail.com
Phone / Airtel: +260 773 695 472
Lusaka, Zambia

[Meta] This Week In PHP Internals | October 22, 2026

Fri, 23 Oct 2026 02:00:06 +0000

Hi Contributors,

This week's episode is out, and it covers two weeks, since the October 15
episode never got recorded (I was in Austin for LonghornPHP, and all
my time went towards polishing my talk instead of working on the
video). Here's the video, plus everywhere else it landed
for visibility.

Same invitation as always: if I got something wrong, reply in this thread and
I'll make corrections. That includes how I'm pronouncing your names.

youtube https://youtu.be/4ze2Re_-gMQ
dev.to https://dev.to/projektgopher/this-week-in-php-internals-oct-22-2026-ii8
mastodon https://phpc.social/@ProjektGopher/117487634385670894
threads https://www.threads.com/@projektgopher/post/De0Y_rYGpBG
bsky https://bsky.app/profile/projektgopher.com/post/3myizo6lprs2e
twitter https://x.com/ProjektGopher/status/2113438312572817588
linkedin https://www.linkedin.com/feed/update/urn:li:ugcPost:7519206561148420096/
pinkary https://pinkary.com/@ProjektGopher/questions/01a16669-04c3-710b-bd17-acbedc8ac5a6

Cheers,
Len

RFC karma request: array_partition()

Thu, 22 Oct 2026 18:50:19 +0000

Hi internals,

I'd like to request RFC karma on the wiki to propose a new function,
array_partition(). My wiki username is: ayoubezzini

The function splits an array into the elements that satisfy a callback
and those that don't, in a single pass:

[$adults, $minors] = array_partition($users, fn($u) => $u->age >= 18);

It returns [$matching, $nonMatching], preserves keys, and takes the same
$mode argument (ARRAY_FILTER_USE_KEY / ARRAY_FILTER_USE_BOTH) as
array_filter(). Today the same result needs two array_filter() passes
with a negated callback, or array_filter() followed by array_diff_key().
The same operation exists as Laravel's Collection::partition(), Ruby's
Enumerable#partition, Kotlin's partition and Rust's Iterator::partition.

An implementation with tests is available as a draft PR:
https://github.com/php/php-src/pull/24568

I'll open the formal [RFC] discussion thread once the wiki page is up.

Thanks,
Ayoub Ezzini

SSRF protection in curl

Thu, 22 Oct 2026 14:58:25 +0000

Is there any reason we should intentionally make this curl specific?
Meaning, we could design support for making it work for streams as
well, couldn't we? Why make a curl specific feature instead of a
language wide one?

SSRF protection in curl

Thu, 22 Oct 2026 14:26:57 +0000

Thanks Nicolas for your message, good to see some traction around the idea.
Before working on the next step; i would love to hear from bukka - he had
some concerns about the api so we makes sure it may be extended.

I would appreciate it if we may discuss the specifics here before I move
forward with a new PR and an RFC.

Have a nice day,

Xavier

Le jeu. 22 oct. 2026 à 09:14, Nicolas Grekas nicolas.grekas+php@gmail.com
a écrit :

Le jeu. 15 oct. 2026 à 11:10, Xavier Leune <
xavier.leune+internals@gmail.com> a écrit :

Hi Sjoerd,

Thanks for reopening this discussion ! I planned to do it in the
coming days too, I'm really eager to see this land in PHP :)
I'm pretty open about the 2 ways to implement it, however the discussion
on 23657 about 22159 suggested a socket class bound to curl only, to make
things easier to manage and to remove the dependency to ext/socket.

In my opinion, CURLOPT_OPENSOCKETFUNCTION with the boolean may be a good
idea. I'm not sure there is a real use case to open a wider support in PHP

this option exists for almost 2 decades and I'm not sure anyone needed it.
For the record I plan to implement the feature in a polyfill extension -
with the same approach that we'll retain for PHP, to offer support in lower
php versions.

There are a lot of small details we can discuss if we retain the
OPENSOCKET_FUNCTION: the signature may be expanded to offer the same level
of data as curl offers
https://curl.se/libcurl/c/CURLOPT_OPENSOCKETFUNCTION.html. This would
make things easier if we want to support a full CurlSocket object later.

There is a first draft here:
https://github.com/xavierleune/curl-hardening
My idea was to use this extension as a sandbox before pushing a new
discussion here, I will follow the API we may agree on for PHP 8.7.

I think the approach in the current extension may address the concerns
expressed by Bukka on 22159, while giving room to expand the support later.

Do you think this approach is worth pursuing ?

Thanks,

Xavier

Le jeu. 15 oct. 2026 à 10:48, Sjoerd Langkemper sjoerd-php@linuxonly.nl
a écrit :

If an application performs HTTP requests based on user input, it is
often desirable to verify that the connection is done to an allowed host.
Otherwise the functionality could be abused to request resources on the
server or on the same network as the server (SSRF).

Xavier Leune made some pull requests to make this possible in curl. The
idea is to hook in a callback that can verify the IP address that curl is
going to connect to.

22159: exposes callbacks such as CURLOPT_OPENSOCKETFUNCTION. These are
supported by curl, but exposing the socket to userland comes with problems.
23657: introduces CURLOPT_PRECONNECTFUNCTION. This is not supported by
curl and is PHP-only, deviating from the normally thin abstraction on top
of curl.

The current plan is to expose only CURLOPT_OPENSOCKETFUNCTION with the
signature function(string $address, int $port): bool. This is pretty
limited compared with what OPENSOCKETFUNCTION can normally do, but at
least makes it possible to do SSRF protection.

What do you think? How can we expose SSRF protection to applications
that perform curl requests?

Regards,

Sjoerd Langkemper

Yes, please make this happen! But don't introduce CURLOPT_PRECONNECTFUNCTION

a CURLOPT_OPENSOCKETFUNCTION bound to the simpler callback that returns
a bool look enough.
I'd use it it Symfony's CurlHttpClient, to replace the blocking call to
the DNS that we have to do today.
It would also be a useful primitive to hack around the blocking DNS we
have to use at the moment - I would build an async DNS resolver out of this
:)

Cheers,
Nicolas

[RFC] Pattern Matching — missing keys and strict int

Thu, 22 Oct 2026 12:30:14 +0000

Hello Larry and Ilija,

I maintain a production PHP application that rejects a model’s JSON reply unless every field is present and of an exact type. Pattern matching is the language feature that would replace those checks. Two outcomes in the current draft would make that replacement accept replies we currently reject. Both are constraints on the rules you already wrote, not requests for new syntax.

The RFC’s array-pattern equivalents use array_key_exists() before comparing the value. A missing key therefore fails the pattern. The implementation note on https://github.com/php/php-src/pull/20574 says the draft reads a missing element as null, so this is true:
['a' => 42] is ['b' => null]
Please keep the RFC text. For this parser, a missing key and an explicit null are different successful results, and a value of any other type is a failure:
function partQuote(array $p): ?array {
    if (!is_string($p['part'] ?? null)) {
        return null;
    }
    if (array_key_exists('quote', $p) && $p['quote'] !== null && !is_string($p['quote'])) {
        return null;
    }
    $out = ['part' => $p['part']];
    if (array_key_exists('quote', $p)) {
        $out['quote'] = $p['quote']; // null is kept; the key was present
    }
    return $out;
}

partQuote(['part' => 'A']);                    // ['part' => 'A']
partQuote(['part' => 'A', 'quote' => null]);   // ['part' => 'A', 'quote' => null]
partQuote(['part' => 'A', 'quote' => 1]);      // null
If ['quote' => null] matched a missing quote, the first two calls would become the same pattern and the stored shape would be wrong.

The same parser requires a real int for a score-like field, in 0..100 inclusive. is_int() is the type check; the range is applied only after that. These all fail:
['strength' => '80']
['strength' => 80.0]
['strength' => 101]
['relevant' => 1]       // `is_bool()`, same rule: no coercion
['relevant' => 'true']
and ['strength' => 80] with ['relevant' => true] passes. An int pattern therefore has to reject a numeric string and a float. A range pattern such as >=0 & <=100 has to do the same when it is standing in for that field; "80" and 80.0 are inside the numeric range and are still the wrong type.

I am not asking for a change to the feature set. The written array patterns already say array_key_exists(), and an int pattern that follows is_int() is what this code can adopt.

Kevin Lopez

SSRF protection in curl

Thu, 22 Oct 2026 08:14:35 +0000

Le jeu. 15 oct. 2026 à 11:10, Xavier Leune xavier.leune+internals@gmail.com
a écrit :

Hi Sjoerd,

Thanks for reopening this discussion ! I planned to do it in the
coming days too, I'm really eager to see this land in PHP :)
I'm pretty open about the 2 ways to implement it, however the discussion
on 23657 about 22159 suggested a socket class bound to curl only, to make
things easier to manage and to remove the dependency to ext/socket.

In my opinion, CURLOPT_OPENSOCKETFUNCTION with the boolean may be a good
idea. I'm not sure there is a real use case to open a wider support in PHP

this option exists for almost 2 decades and I'm not sure anyone needed it.
For the record I plan to implement the feature in a polyfill extension -
with the same approach that we'll retain for PHP, to offer support in lower
php versions.

There are a lot of small details we can discuss if we retain the
OPENSOCKET_FUNCTION: the signature may be expanded to offer the same level
of data as curl offers
https://curl.se/libcurl/c/CURLOPT_OPENSOCKETFUNCTION.html. This would
make things easier if we want to support a full CurlSocket object later.

There is a first draft here: https://github.com/xavierleune/curl-hardening
My idea was to use this extension as a sandbox before pushing a new
discussion here, I will follow the API we may agree on for PHP 8.7.

I think the approach in the current extension may address the concerns
expressed by Bukka on 22159, while giving room to expand the support later.

Do you think this approach is worth pursuing ?

Thanks,

Xavier

Le jeu. 15 oct. 2026 à 10:48, Sjoerd Langkemper sjoerd-php@linuxonly.nl
a écrit :

If an application performs HTTP requests based on user input, it is often
desirable to verify that the connection is done to an allowed host.
Otherwise the functionality could be abused to request resources on the
server or on the same network as the server (SSRF).

Xavier Leune made some pull requests to make this possible in curl. The
idea is to hook in a callback that can verify the IP address that curl is
going to connect to.

22159: exposes callbacks such as CURLOPT_OPENSOCKETFUNCTION. These are
supported by curl, but exposing the socket to userland comes with problems.
23657: introduces CURLOPT_PRECONNECTFUNCTION. This is not supported by
curl and is PHP-only, deviating from the normally thin abstraction on top
of curl.

The current plan is to expose only CURLOPT_OPENSOCKETFUNCTION with the
signature function(string $address, int $port): bool. This is pretty
limited compared with what OPENSOCKETFUNCTION can normally do, but at
least makes it possible to do SSRF protection.

What do you think? How can we expose SSRF protection to applications that
perform curl requests?

Regards,

Sjoerd Langkemper

Yes, please make this happen! But don't introduce CURLOPT_PRECONNECTFUNCTION

a CURLOPT_OPENSOCKETFUNCTION bound to the simpler callback that returns a
bool look enough.
I'd use it it Symfony's CurlHttpClient, to replace the blocking call to the
DNS that we have to do today.
It would also be a useful primitive to hack around the blocking DNS we have
to use at the moment - I would build an async DNS resolver out of this :)

Cheers,
Nicolas

[VOTE] [RFC] IntlRelativeDateTimeFormatter

Thu, 22 Oct 2026 01:44:18 +0000

Hello,

The voting process of the IntlRelativeDateTimeFormatter RFC 1
has ended. The voting results are: 25 Yes, 0 No, 0 Abstain.

According to the results, the RFC is now officially accepted.

Thanks,
Weilin Du

[RFC] Io\Terminal

Wed, 21 Oct 2026 18:44:53 +0000

Hi Tim,

I suggest to wait with the vote for things to have calmed down.

Understood, sorry about the timing. I’ll hold off on the October 23 vote
and give everyone more time to review. I’ll send a fresh Intent to Vote
notice once things have settled down.

Regards,
Pratik

[RFC] Io\Terminal

Wed, 21 Oct 2026 18:21:15 +0000

I plan to open voting on the Io\Terminal RFC on Friday, October 23.

https://wiki.php.net/rfc/io_terminal

If there are any further questions or concerns, please let me know.

Large parts of the core team have been busy in the past week(s) due to
today's security release. I assume not everyone has been able to catch
up with RFCs in that time (me included, I did not get around to reading
the latest iteration of your - non-trivial - RFC).

I suggest to wait with the vote for things to have calmed down.

Best regards
Tim Düsterhus

PHP 8.6.0RC4 is available for testing

Wed, 21 Oct 2026 16:21:03 +0000

PHP 8.6.0RC4 has just been released and may be downloaded from
https://downloads.php.net/~mbeccati/

Or use the git tag: php-8.6.0RC4

This version also contains the fixes for two critical vulnerabilities
that can allow unauthenticated remote code execution. Everyone running
earlier builds of PHP 8.6.0 is strongly encouraged to update immediately.

This is an early test release and not intended for production use.

Windows binaries are available at:
https://www.php.net/pre-release-builds.php#windows

Please test it carefully, and report any bugs at
https://github.com/php/php-src/issues/new?template=bug_report.yml
on GitHub.

8.6.0RC5 should be expected in ~2 weeks, i.e. on 5 Nov 2026.

Hash values and PGP signatures can be found below or at
https://gist.github.com/mbeccati/39f97a084c818707537c9316206eb74f

Thank you, and happy testing!

Regards,
Matteo Beccati, Joe Ferguson & Daniel Scherzer

php-8.6.0RC4.tar.bz2
SHA256 hash:
60d433d768e9c017632a0402048b0d189979d7659483db65df6790018e10d306
PGP signature:
-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQBaJXemkdREdU3puaRNP8wvFqZtQUCatjPwAAKCRCRNP8wvFqZ
tYpbAQCNKU7pP3CYk7m/V7HqJPE38BAuxRPSBsCHh6yKEGBRnwEA9UzLO1WLNcTB
VjMJrBMTkvCzhK0VxrwbffAKh7qL6wU=
=UU3o
-----END PGP SIGNATURE-----

php-8.6.0RC4.tar.gz
SHA256 hash:
ac4e19a92fc2d8a6a3b5310b149330475e602a8fd8f9278976bb1ee1b6b6665e
PGP signature:
-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQBaJXemkdREdU3puaRNP8wvFqZtQUCatjPwAAKCRCRNP8wvFqZ
tcJLAPwPRYRuJ1oJoRvBxBp3MMWokuV6y6jeYeHoC2EVIKozVQEAi3FOu/zGM6YA
vQRUHxI7WyYBxfdSoDJVN846Zu3lkAk=
=Rz8p
-----END PGP SIGNATURE-----

php-8.6.0RC4.tar.xz
SHA256 hash:
93f208da9ae059bf6863b0e1d101e6c6475a7b0f0acbf6c084950ab522f514d8
PGP signature:
-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQBaJXemkdREdU3puaRNP8wvFqZtQUCatjPwAAKCRCRNP8wvFqZ
tSmpAQDoZzynreTcJG4x8ORk/37jLFkpYanVUs5AfQoUriSFlwEA2AnSbnXiDtae
mZtN087ADtwF9DjmDNz1stVLbjHA0QE=
=ubPo
-----END PGP SIGNATURE

PHP 8.4.27 Released

Wed, 21 Oct 2026 14:32:43 +0000

The PHP development team announces the immediate availability of PHP 8.4.27.

This is a security release fixing two critical vulnerabilities (CVE-2026-109618, CVE-2026-109619)
that can allow unauthenticated remote code execution.

All PHP 8.4 users are advised to upgrade to this version.

There are no complete mitigations, updating is the only safe choice.

See the security advisory for details:
https://www.php.net/archive/2026.php#2026-10-21-5

For source downloads of PHP 8.4.27 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.

Release Announcement: https://php.net/releases/8_4_27.php
Downloads: https://php.net/downloads
Windows downloads: https://www.php.net/downloads.php?os=windows&version=8.4
Changelog: https://php.net/ChangeLog-8.php#8.4.27
Release Manifest: https://gist.github.com/NattyNarwhal/fba184b51d4397c46a082e71f10ee295

Many thanks to all the contributors and supporters!

Regards,
Calvin Buckley, Saki Takamachi, and Eric Mann

php-8.4.27.tar.bz2
SHA256 hash: b2530a877c722f4b08c9e174a30cb08bac2b7e1903ee6e9e315f0aa9f5f82c24
PGP signature:
-----BEGIN PGP SIGNATURE-----

iJEEABYKADkWIQSdf5mgy48FyKaVjWJWqXr3YAo5pgUCatYuXRsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwwLDMACgkQVql692AKOaZJ+QD+N5jC7Og89QDafkw23xHB
7YML1Ad26UiFzG1wcMENZRIA/066M0vjg+Q1x2HQi4f+07YtqhCIN4IZqiDQEzUz
xAcE
=MAOU
-----END PGP SIGNATURE-----

php-8.4.27.tar.gz
SHA256 hash: 5bafed9994c1a49796b25b5f61c22c9183bfe046b6acc7b363842d03c77f972f
PGP signature:
-----BEGIN PGP SIGNATURE-----

iJEEABYKADkWIQSdf5mgy48FyKaVjWJWqXr3YAo5pgUCatYuXRsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwwLDMACgkQVql692AKOaY3qAEAgkdyhOWhQhtETdt3JYNZ
ikZrPY9u29jZaMmjoPj8ubEA/24terMZUo3PRBzmb7phybo6A0IK7Fu3GzqZNKsR
ub0H
=lyID
-----END PGP SIGNATURE-----

php-8.4.27.tar.xz
SHA256 hash: dcf93923b0e38e0d5252b25b796520b5a47761a08b3488b6d0b5d1115764d3f0
PGP signature:
-----BEGIN PGP SIGNATURE-----

iJEEABYKADkWIQSdf5mgy48FyKaVjWJWqXr3YAo5pgUCatYuXRsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwwLDMACgkQVql692AKOaZf7gEA7j/NMWQy9TbvQ4IhAajS
gOO1tgMmpSTh3sPTOQQWfIkA/R363Ndrs3VJxYGx1pSZcstwfCwYXWbhUNGUsu6Z
PjEJ
=uvS8
-----END PGP SIGNATURE

PHP 8.2.35 Released!

Wed, 21 Oct 2026 14:16:54 +0000

The PHP development team announces the immediate availability of PHP
8.2.35.

This is a security release fixing two critical vulnerabilities
(CVE-2026-109618, CVE-2026-109619)
that can allow unauthenticated remote code execution.

All PHP 8.2 users are advised to upgrade to this version.

There are no complete mitigations, updating is the only safe choice.

See the security advisory for details:
https://www.php.net/archive/2026.php#2026-10-21-5

For source downloads of PHP 8.2.35 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.

Release Announcement: https://php.net/releases/8_2_35.php
Downloads: https://php.net/downloads
Windows downloads: <
https://www.php.net/downloads.php?os=windows&version=8.2>;
Changelog: https://php.net/ChangeLog-8.php#8.2.35
Release Manifest: <
https://gist.github.com/saundefined/35fb84fc90161b9e920a0992bda7a47c>;

Many thanks to all the contributors and supporters!

Pierrick Charron, Sergey Panteleev & Ben Ramsey

php-8.2.35.tar.bz2
SHA256 hash:
0f43efd1ac24d4f90002c8d4d570bf4c4d59fa14313bf270aae8cf04d9dfdef3
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQJPBAABCAA5FiEE5gkT5N8gmQfY4w2WZZqXyc8qeVoFAmrVx/4bFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMCwzAAoJEGWal8nPKnlaFq0P/2W91rkguw9eQggyFMTs
l5pGJGNZrashKQ6LfOyesKPFAXLDxOKBf4LJBaSDt4sNFXoaCK+cMgZfaH4xOakS
79aQPJx1oxdAEjVtwZ+0QY/dLo3dE/0AteohYuj517k1xQVA1NhLrWltuCW0JIZP
b+P8mn7d//MtwRX936tRVdO4IxljUe5Ns/QjVeIbH+4UpCuWJ+kmgFFQZMTj5NaR
oIjFRqyKT/CD5KtlTIfeXaXnKjqEvt8RFxZQRRqikhY3Ef1ZcMmKc4R6Rp2Kp9g9
p7uaiIid0sPXggMiARqZ0QUbfhhZJbquZlPgc9i/RMsIUPSz6u+3QAzIoKbg1z9z
3syVMg00mn1H/7QJQRMzVlBTXKa7Ne0VOToQXPxCiGIwf8ccG8vFb8GpKLVcaS/n
SPV9pjrCzLjaguM5UtH1iwQi/H5HxRhEfQI+P/Yq/dJKnhDVJJc6nmPi5qa4ePLZ
/azbGp1jvUDxAyBLq9vXiN5Derv20YTf/4qdXVGUmtVumg3CIpUT3s0jI+JA7lnF
r3hoVyhVOMi3+jEVy47u8TrCU5pR4GTLz1+Cyhq8spagdY3yMzDLBmJ/0F1eqP+Y
nqeB5538cI69U1aqwALtzE2FMy44OocyovgvTwBnHg5bIU2farKJJ2O2glZpPTiA
NUJcE5ydh9cTJx7JoEuUHKJ6
=T7Lq
-----END PGP SIGNATURE-----

php-8.2.35.tar.gz
SHA256 hash:
9db4204f0a2d1911277ae832185e07bb4c3b3559772753a70d2968ca346d6910
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQJPBAABCAA5FiEE5gkT5N8gmQfY4w2WZZqXyc8qeVoFAmrVyAcbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMCwzAAoJEGWal8nPKnlaCTkP/i+SgGgM6SwcL1gg9fXn
fn31m/MEPGmbibQ0qirWURTAyLrU4Fdxn/JbZnU6dnC75MiZoB7l+Geux1vopJcq
fPNiRptjsoGJ5UhgNqokiSL52CrVXdaf8IRiW/2uAeOaVjK+oM0cC9CBz21AkKzG
EVNoWslWMHW4FI5HunSu7l1OoptGN2g5DIUeEoWxE8PI0VNlBmRtdwED4OOVvWr1
F1AyiLcsOZEXegWvW3A16O5gA9TlU+yWU+HGkikyPEGRlb0BT2f9ntUwyS1FkzAJ
dEk2txvvcPdhVT/ZDGRpnk2MGDbSXf3nKxs/509x2MrDemT7R0A85Vxd2b3iRSR2
t/etfQxOwGk4l3265ydOMBDbXgUfKUiPkvGYhUDMgMnkfI1Cj/SfJDoGyaDtbOn5
xiIuKwFlRPPKgmJkU85j9A/+zQsZEfGvEGDCNt6mSnXHw5m+4nxbs563aE+4XqXh
BtBeykSkoNsRj8ijKpJJC/Ygd0+faNscww/imbsAYNgIXBNgz+ApjxEa96mcVVU8
s++wlleO0+KTFsFWGgw/pXJwF8FO0SnWMDvLMHTXeN6wLxEef3f6EL+X052ixB9m
r+kI7tk+dWWKDj07Uja/CHnmreHTJBZ51tHLO7lXbHRSkykFPpze7GmxmEzXUYZo
KBzDVOaFSv3PrHeoLZDXqEvf
=dsL2
-----END PGP SIGNATURE-----

php-8.2.35.tar.xz
SHA256 hash:
5737b98601fe5ab1b8c5db0c82ed3158acb9283ed3081ffe2faffb9ac81455e6
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQJPBAABCAA5FiEE5gkT5N8gmQfY4w2WZZqXyc8qeVoFAmrVyAgbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMCwzAAoJEGWal8nPKnlakfEP/iFvT4mcDQcXBeMM6CRm
SzjpTs7moCgkxQzVISdVOmbFlmdUGjXFgvjlnKbOpw9PNhaUDOR3FfhLYB1XKKCs
k5XsvF8C9Qh0qM3whwfKXUA2fz7GFsFX8Oe7cOYxKrtdld0rxvm7EbVCpHv+DF34
TAjKRKL/p4aH5ntfHuuV0+Ow2J1D+Ko8vs3EBnxupPxmbn85W8BEVAj6hRiUFmd+
zU3pGdBv/naQG/N+NCiSWkWn7VghY6mUf1nwXkdzFrVfQBSvbG5fxiO41RTHzHKB
iSzOtaMK8Wy6M2+mGdn+UlY+5nSqiZk/cWmTO3mXlRrr1YPTNKnEnrkcDKwCNguC
7nTwNblOCaugiOlNNXrXbye9mlzsqFkq9ZrSqb52h5ctDPeXMDpZ8iJKNtDqfX77
uoUbbRoDzA4xz6osMj237Mtbu6kqPI+QOdAOfBfRiCYWt8SVbsXD+qGUU8AffqWR
R+fmMlm92ngkhITQx6jN3csTflgWCsBSrR5xirpy5fehMDGZpZ1BSFgILlK3PUPw
Bpi+rCTiTBKni42uWrqNMXxVYGVS/MIWDK5alXQ6kE5ThwuNMSMaMJvJxZuTViUi
r9o8X6IonYC0Et3ZpJuWKVjRcwSYzOZ/tKGRB00LKAKXyFyylWhVffAYzEgZSwvH
qEQfrM2/LyS0lMeOkhjSStPB
=P6Hg
-----END PGP SIGNATURE-----

My thanks to everyone who worked hard to fix these CVEs the past few days!

PHP 8.5.12 Released

Wed, 21 Oct 2026 14:03:59 +0000

The PHP development team announces the immediate availability of PHP 8.5.12.
This is a security release.

This is a security release fixing two critical vulnerabilities
(CVE-2026-109618,
CVE-2026-109619) that can allow unauthenticated remote code execution.

All PHP 8.5 users are encouraged to upgrade to this version.

There are no complete mitigations, updating is the only safe choice.

See the security advisory for details:
https://www.php.net/archive/2026.php#2026-10-21-5

For source downloads of PHP 8.5.12 please visit our downloads page.
Windows binaries can be found on the same page.
The list of changes is recorded in the ChangeLog.

Release Announcement: https://php.net/releases/8_5_12.php
Downloads: https://php.net/downloads
Windows downloads: <
https://www.php.net/downloads.php?os=windows&version=8.5>;
Changelog: https://php.net/ChangeLog-8.php#8.5.12
Release Manifest: <
https://gist.github.com/DanielEScherzer/9fce78e81e004f0398e249e1fe0df5b8>;

Many thanks to all the contributors and supporters!

Regards,
Daniel Scherzer, Volker Dusch, and Pierrick Charron

php-8.5.12.tar.bz2
SHA256 hash:
ffb60edc437ced63b5137e4984db379a8111c50049c711510d8b958277efc1a8
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE2VwDvHAr6VFTRK4zdORLyQZ3AaUFAmrWUKQACgkQdORLyQZ3
AaU1QRAAj951A3VHXxL+rfVce64T0cCI6bde+BqSWmxMifKN29UkVDOrzxkzNYZK
993NLsmMPMN00FlJsXXlZ8RuOBgTzv8HHnKTjJdxtbXDlaHWiYNZT5hIY9/JpLe8
1pHztBB4GwGxtYqFleg2w0ya52To191dTxqkbE9xMyNGxY6b14K1f+CyWkYlbxjD
c/mnsCJ26zzVWfU1ZhEIGjC5ykXQcIZRwMbwdywnvQo63DzxqT5gFwKq2Lkdy0oM
/RCXWYBQdXsLbkanC2jzAceubm1Rk1MQHMtbvEkY/IwkGR73ky4q/Yig99K3grID
sVYXUVhqxMnPFWMManQPC+aKE9rrtgJkY84rDLFYWTmi7qW81lYBOLWizH5oFhBY
fSomfaNNqGuddn9Swrqn07R+gA1JAdiSWq1ViIrE5TN2J6ytey0n4mepThdNq4oZ
FN+jmH/MkftDWMgDrt0iSq/Kk4nAcjsBc28YIku29J45J9zE9HkejoEBaTzDXUdC
Y5IIjlF8NEzPZJhppM4WmvP1HzcocmtMjzjyBY82Z+sw+oUzh+6thCU4MYIV89YF
gQvVhM77r/3MxsA3JNPgF9B6e/vK9JEptlAl9gzLDwJCW+VCWg4wWgTFvW4Eah32
kMwu8qYX/8hrPv4JKvqeADfGWUJvLKGQV9REeA6jBSy9yD+ZvC4=
=gNxr
-----END PGP SIGNATURE-----

php-8.5.12.tar.gz
SHA256 hash:
81a0f450349e84b08eb43faa85f8a4c835684f3cc1c50471775d1317a046c525
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE2VwDvHAr6VFTRK4zdORLyQZ3AaUFAmrWUKgACgkQdORLyQZ3
AaVyQg//SiL5miUAcCERQkmIpKyk9ZNvTX1NYhs5YEF+eNpUoUAEHUBdmbAqJ17G
P6Z8cMurmQqGVX2dc4YSuHqjmFiBzEQpAOqzVg9AJaKFm4L9mQyI3uB/+p+T5Eu7
2biVKD1U4EcJ0AWwsCLB1wOH3zY4FS+flovZLiM8o+VEnJnoM+X8THbF6NuWyjQk
5v8/5xrPFHMycae63gbq+e9P7OKuaMdOXmkdTGzl20sn14M2rmQoqnExBkMb81fV
lC7AT9X4X7ATOCkzBNAuY4MGSqJmnPQrh8SSSuEmNqltqCIw56u1lvf7x1QXPQiJ
GPHkzfiFf9+03QO95jos1RDPnNNaKJsGc/GR/5KHKzSEbA9nDTPfTBIffQOAiNu5
Ii3Otv4Q0cU7d7lHf0oJ9U/gdU/Ixv6Y8gYs2gEABu4T1v1kumObMSaT4wxSNeJh
UQqOX//JCz+x9cAaZSie1qTUObmKDbP4HnOwauY6fVfdYXcVTLB5KekhCrbEULT8
/A2NhOZiQHAigwE6EfI1L9Qwta5/YFLkI9xbY9fLi31HnCUNc70X36FzokVTYQeb
ju9d9VgpFhe57MTjOXiJExAcWbSFsM7smDYibWQak4pGT/kXCQ8iJT686aovHso+
rbhTDnde55bxv7ieZcnr42AjwlCIQ2lFexmWUan1CHyE2sczjvg=
=bZwM
-----END PGP SIGNATURE-----

php-8.5.12.tar.xz
SHA256 hash:
08bc2eba2a588654ade1357174aa646b761556c862dda0678345ee29ed481209
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE2VwDvHAr6VFTRK4zdORLyQZ3AaUFAmrWUKgACgkQdORLyQZ3
AaWt8BAAkiRCqB8qc8OoXos8YBES/67MKcpKh5es0geSOG8TuuxkkNG7rZfpAAU7
G32U30SCFYCpUZT5C6OQWV0EHdqDxvgRdpv5v3C/nxQSw320DyYIbJPWByxtq1WE
V/KO4/PtGLPNIC1Tqgh3stxh1sOYtAPY+A07xd59l8rYpw0/hRWcpufrmrmx46te
TrH3ZNEXkBZPWmaS2gcUkB3hDgol5gB+0vtAedOef3uQcWnmxTOawrIaAoTNtGIU
3tQQHtrzcPSimV9LBlScL1T8KZFJKb4ZMvYOF7WJbmbPgWbbnqqb/wznJb7/KNRh
HmAuhDe2cPuJuN2J11NAZ1bw+/6AvTok8Vt0jyEPRaTVcUW7NG0PZgLsYf2hPXbG
YETMwl39IDM7CN+YPUpYOgdXDlrjwu3ZB7A563y7L23kGidlO6oPU4u+Lp2zCZ1S
vPWxDuR3KkWKTjwAJiwfAJEAmPvXl2lSrMkqldP9soiGSH7BFHPcBnB12lJTtTXy
VcJwe9plmG8K3LFYYnLAZjVGfl+xqH2RRRxkmt8sUaKNQSxquXnTOfF4CpZSs4E4
dV/juvxwUla4ahqR29UvlhmuR/fI4wgoifmCIJQxMmakBCnBGxcRaZReBwugDZRh
7v5UfTk06YqT4kFcAsqz40EeJqvRyLT8LqkaaEOBlP8T1VSxuZU=
=EFmu
-----END PGP SIGNATURE

PHP 8.3.36 Released

Wed, 21 Oct 2026 14:01:22 +0000

The PHP development team announces the immediate availability of PHP 8.3.36.

This is a security release fixing two critical vulnerabilities
(CVE-2026-109618, CVE-2026-109619) that can allow unauthenticated remote
code execution.

All PHP 8.3 users are encouraged to upgrade to this version.

There are no complete mitigations, updating is the only safe choice.

See the security advisory for details:
https://www.php.net/archive/2026.php#2026-10-21-5

For source downloads of PHP 8.3.36 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.

Release Announcement: https://php.net/releases/8_3_36.php
Downloads: https://php.net/downloads
Windows downloads:
https://www.php.net/downloads.php?os=windows&version=8.3
Changelog: https://php.net/ChangeLog-8.php#8.3.36
Release Manifest:
https://gist.github.com/ericmann/bd87f4e5a8b6d0a0a9f7bda353cc4283

Many thanks to all the contributors and supporters!

Eric Mann, Jakub Zelenka, and Pierrick Charron

php-8.3.36.tar.bz2
SHA256 hash:
46f4b45e3688ed2b1819015a7b532c15b51cc055bdd3b13fd00ddfeebeedcd5f
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEESx/A2d+SMhztn2FdvsVV4ioUNVMFAmrWI18ACgkQvsVV4ioU
NVP08hAAkPHoBkbZZrd++fuyrS/8mz3qBrGBqxvfvWQIAK8M1T/5iRzSvzQuUWy1
6QYEnTedJLyFnM4f0mMrtDMswj7BkWz8SgJ8Akyh4GX+OVeg3Q8FNvhb09nqTrLg
/Soy6z7AcKcnrofFpJhuLcoTBxp7UamJQQgA7zOICjjH2CDOxxEFcek/DklvCW1R
9gIlMYCk3VXNmAqHU7STvPLnrBzX/xKkqFXnqaLjWMBzgL9n0r0lHyPq+2JDHMho
UyFCcmz9/c3gwx8/OZvnA97+w/ZQf5FjnB4z2DWuVb+TJiAzKBpjniqullnrH5LA
B8UPu5vrxUECkHNMni+Tou6Y9i2t0SF2jBYaTF/c9fXBRyp+ymiLciEQMgHAhRIZ
gAcI3KbJe/z6tUGiOs2Wxoeot8FS5U0o5OwNE6iurDg+iC3PpwmOyorz3psNdlpd
nRBVGL+b32KNg/co7nT/GU6LOMetDR5uWf2+f0C4tlmHnQXT9uyQZWljY9xkKUjK
Uqph8grS/H3m2YiGH7hRTro8Qj8CfX/MZAky/l2fU3O8wPa/1WIkEBSBLYpjlrDB
17gzXQxFBdjEhQx4E7kpyj03Va7hc9at9nAG4Kjc7W8e92uiOn2RgjluuNuWnp2m
oqjdQSKzItn0b5pp+1BfwUTbkCpiz/JwpQZKuJPbse88p2/C/G0=
=JPY/
-----END PGP SIGNATURE-----

php-8.3.36.tar.gz
SHA256 hash:
c93f3441f87f6ab156bef4432db215d7e61ca2c0183bb3a2aa28d9886ab59f53
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEESx/A2d+SMhztn2FdvsVV4ioUNVMFAmrWI18ACgkQvsVV4ioU
NVM5Uw/8CWc6ccvc2gwPb9Yq6fUlIZyeLZq1KZC3VE9dRphu0FEk+/hch7wMeBp5
GAHnYHcLyVEIfINywiArU4mkIhWtHPMowZKpzjx44hxzvsEmT+dcn99xcahIKER2
ehBbn0nw65Ki7fsi7yPqTLqqICXrdtDh6JiF2qIRFRXTq3bmQZ6gadM16ANK1gko
IYFcvHsoj/+SeoXwver++PlseJp5H9gOA4qUV+OVgrVHMCEdnhyhtM+II+s9z6fB
nv+va67QGz1S1Cxhv439vEnv/YFjAjWouZOzYO3SnoBzeWvvdod32zEQdiXz5N9v
vKpkl45rJ+4hjpxaoHdmwfMzCVK8N7FV9l0YF24OqKdakcZgzI5LtYWphGmBRYjU
e9yG7k1WyJVogb7nPay0UMXFjjyCMqMnXlK1BVuDwTh8xpPUf/s1FF0pqcUMbxog
VX9ZU3HJNAlKi2JuHHF50lhngY5e4UK3Dp0+hX2clSWETo/hZHueYUj3zTz9ZnO9
XIYue3O4qfpLM6+P7LFXTB9Ht9wro4DxCLnAmIjUvRP8Uyq9r4PK6KtnSG3i4MrR
S3WjkuIY8fo0pRHmm95ZReakgseAnZDjDRonjUp1kmv/xrT4X+l9m5C/wd2TfvTH
wTI4x1l7fPNtaaQ6Qe3Z+GZQd95VafmbtnXA7/qNjrvlRwvc6OU=
=LlH8
-----END PGP SIGNATURE-----

php-8.3.36.tar.xz
SHA256 hash:
dd54693aa334c5c4d72e9aee96b082c2473750a18a6c1d105789c93a3b1692fd
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEESx/A2d+SMhztn2FdvsVV4ioUNVMFAmrWI18ACgkQvsVV4ioU
NVNs+RAAj/QMSy3YSQwr+rkUD0qaMvO0fZET3dBNxEtdMCM1iQSWzBJi9Llty7De
OfaCXOK/NZpO3CICJifir0XY9eU6uHWl7wpo8YQHXcQ5EirDX3jeNEHMoPnx3jsX
NX7j4fpcj3hfLuZLW1vyKhVmXCenrhJDPS+buta5g79OXpGUrJ0hy2IFKmt049BO
sxDOjQZANd46RApf8GapEvpDClkTTSnnEh8v0S9ripShe4oECTzW+bDKEtsZVImv
xpZJqC0sJ7Y9i4M7dVqfNjohEfj+Mh0NvfR8l4PHHko5RVz7A3EueThM8WZ4i2qr
iwKIOSBhdzcgfEGwKKGzO4yjcf3pCvcANh8Oa6En3fSXwoJgMZJhTczCh7cFJIQS
e58b8dMmSAsQLcgB1LQr7hulHOQLt4lDzO/iR4rT3C3bBaZsZfjfyZxNMFxUFgSm
ZUrXgGGbDqtAtoif80OzXLMT+S8G3dks/nRnn+hVy0QDxjawIGAIutZVAVSA9Ixp
UsxS1N6v7/WWUHuuKBQEYib7N+QXPIgJrr5vF3D7s7bF3RN2jIDlIvKVvp/Bz2xr
x7rKFtIN3XsLOkS9qlL4XcZN8gMZkLh04VJ7gmEO5L/mOkk+PJidMjbCimASERjJ
/FjxHzlKkku17fn7E1T6LPmrIN1MvA0B66iJhXWgIoMp7h+bTqM=
=FtbT
-----END PGP SIGNATURE

PHP 8.2.35 Released!

Wed, 21 Oct 2026 14:00:14 +0000

The PHP development team announces the immediate availability of PHP 8.2.35.

This is a security release fixing two critical vulnerabilities (CVE-2026-109618, CVE-2026-109619)
that can allow unauthenticated remote code execution.

All PHP 8.2 users are advised to upgrade to this version.

There are no complete mitigations, updating is the only safe choice.

See the security advisory for details:
https://www.php.net/archive/2026.php#2026-10-21-5

For source downloads of PHP 8.2.35 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.

Release Announcement: https://php.net/releases/8_2_35.php
Downloads: https://php.net/downloads
Windows downloads: https://www.php.net/downloads.php?os=windows&version=8.2
Changelog: https://php.net/ChangeLog-8.php#8.2.35
Release Manifest: https://gist.github.com/saundefined/35fb84fc90161b9e920a0992bda7a47c

Many thanks to all the contributors and supporters!

Pierrick Charron, Sergey Panteleev & Ben Ramsey

php-8.2.35.tar.bz2
SHA256 hash: 0f43efd1ac24d4f90002c8d4d570bf4c4d59fa14313bf270aae8cf04d9dfdef3
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQJPBAABCAA5FiEE5gkT5N8gmQfY4w2WZZqXyc8qeVoFAmrVx/4bFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMCwzAAoJEGWal8nPKnlaFq0P/2W91rkguw9eQggyFMTs
l5pGJGNZrashKQ6LfOyesKPFAXLDxOKBf4LJBaSDt4sNFXoaCK+cMgZfaH4xOakS
79aQPJx1oxdAEjVtwZ+0QY/dLo3dE/0AteohYuj517k1xQVA1NhLrWltuCW0JIZP
b+P8mn7d//MtwRX936tRVdO4IxljUe5Ns/QjVeIbH+4UpCuWJ+kmgFFQZMTj5NaR
oIjFRqyKT/CD5KtlTIfeXaXnKjqEvt8RFxZQRRqikhY3Ef1ZcMmKc4R6Rp2Kp9g9
p7uaiIid0sPXggMiARqZ0QUbfhhZJbquZlPgc9i/RMsIUPSz6u+3QAzIoKbg1z9z
3syVMg00mn1H/7QJQRMzVlBTXKa7Ne0VOToQXPxCiGIwf8ccG8vFb8GpKLVcaS/n
SPV9pjrCzLjaguM5UtH1iwQi/H5HxRhEfQI+P/Yq/dJKnhDVJJc6nmPi5qa4ePLZ
/azbGp1jvUDxAyBLq9vXiN5Derv20YTf/4qdXVGUmtVumg3CIpUT3s0jI+JA7lnF
r3hoVyhVOMi3+jEVy47u8TrCU5pR4GTLz1+Cyhq8spagdY3yMzDLBmJ/0F1eqP+Y
nqeB5538cI69U1aqwALtzE2FMy44OocyovgvTwBnHg5bIU2farKJJ2O2glZpPTiA
NUJcE5ydh9cTJx7JoEuUHKJ6
=T7Lq
-----END PGP SIGNATURE-----

php-8.2.35.tar.gz
SHA256 hash: 9db4204f0a2d1911277ae832185e07bb4c3b3559772753a70d2968ca346d6910
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQJPBAABCAA5FiEE5gkT5N8gmQfY4w2WZZqXyc8qeVoFAmrVyAcbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMCwzAAoJEGWal8nPKnlaCTkP/i+SgGgM6SwcL1gg9fXn
fn31m/MEPGmbibQ0qirWURTAyLrU4Fdxn/JbZnU6dnC75MiZoB7l+Geux1vopJcq
fPNiRptjsoGJ5UhgNqokiSL52CrVXdaf8IRiW/2uAeOaVjK+oM0cC9CBz21AkKzG
EVNoWslWMHW4FI5HunSu7l1OoptGN2g5DIUeEoWxE8PI0VNlBmRtdwED4OOVvWr1
F1AyiLcsOZEXegWvW3A16O5gA9TlU+yWU+HGkikyPEGRlb0BT2f9ntUwyS1FkzAJ
dEk2txvvcPdhVT/ZDGRpnk2MGDbSXf3nKxs/509x2MrDemT7R0A85Vxd2b3iRSR2
t/etfQxOwGk4l3265ydOMBDbXgUfKUiPkvGYhUDMgMnkfI1Cj/SfJDoGyaDtbOn5
xiIuKwFlRPPKgmJkU85j9A/+zQsZEfGvEGDCNt6mSnXHw5m+4nxbs563aE+4XqXh
BtBeykSkoNsRj8ijKpJJC/Ygd0+faNscww/imbsAYNgIXBNgz+ApjxEa96mcVVU8
s++wlleO0+KTFsFWGgw/pXJwF8FO0SnWMDvLMHTXeN6wLxEef3f6EL+X052ixB9m
r+kI7tk+dWWKDj07Uja/CHnmreHTJBZ51tHLO7lXbHRSkykFPpze7GmxmEzXUYZo
KBzDVOaFSv3PrHeoLZDXqEvf
=dsL2
-----END PGP SIGNATURE-----

php-8.2.35.tar.xz
SHA256 hash: 5737b98601fe5ab1b8c5db0c82ed3158acb9283ed3081ffe2faffb9ac81455e6
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQJPBAABCAA5FiEE5gkT5N8gmQfY4w2WZZqXyc8qeVoFAmrVyAgbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMCwzAAoJEGWal8nPKnlakfEP/iFvT4mcDQcXBeMM6CRm
SzjpTs7moCgkxQzVISdVOmbFlmdUGjXFgvjlnKbOpw9PNhaUDOR3FfhLYB1XKKCs
k5XsvF8C9Qh0qM3whwfKXUA2fz7GFsFX8Oe7cOYxKrtdld0rxvm7EbVCpHv+DF34
TAjKRKL/p4aH5ntfHuuV0+Ow2J1D+Ko8vs3EBnxupPxmbn85W8BEVAj6hRiUFmd+
zU3pGdBv/naQG/N+NCiSWkWn7VghY6mUf1nwXkdzFrVfQBSvbG5fxiO41RTHzHKB
iSzOtaMK8Wy6M2+mGdn+UlY+5nSqiZk/cWmTO3mXlRrr1YPTNKnEnrkcDKwCNguC
7nTwNblOCaugiOlNNXrXbye9mlzsqFkq9ZrSqb52h5ctDPeXMDpZ8iJKNtDqfX77
uoUbbRoDzA4xz6osMj237Mtbu6kqPI+QOdAOfBfRiCYWt8SVbsXD+qGUU8AffqWR
R+fmMlm92ngkhITQx6jN3csTflgWCsBSrR5xirpy5fehMDGZpZ1BSFgILlK3PUPw
Bpi+rCTiTBKni42uWrqNMXxVYGVS/MIWDK5alXQ6kE5ThwuNMSMaMJvJxZuTViUi
r9o8X6IonYC0Et3ZpJuWKVjRcwSYzOZ/tKGRB00LKAKXyFyylWhVffAYzEgZSwvH
qEQfrM2/LyS0lMeOkhjSStPB
=P6Hg
-----END PGP SIGNATURE

[RFC] [VOTE] Throw exception for invalid characters in number base functions

Wed, 21 Oct 2026 13:32:18 +0000

Hi CHU Zhaowei,

Thank you for your explanation.

I’ve voted against on this RFC, and the only reason is the choice of a generic \Exception.

Yes, this is fair. A more specific exception is desirable, but currently not easy to get right. Throwing a generic Exception now makes it possible to change this later to something more specific.

InvalidArgumentException, which was the exception originally agreed upon, wasn’t brought up.

I would have preferred it if you brought this up during the discussion phase.

InvalidArgumentException is definitely the incorrect exception to use. First, because it is documented as indicating that the argument is not of the expected type. Second, because it extends from LogicException, which indicates a programming error. Having these function fail is not necessarily programming error, it could be unexpected user input. This was also the argument Tim made against ValueError.

During the discussion phase, Lazare suggested UnexpectedValueException, which is also an SPL exception and also not semantically correct. So while InvalidArgumentException specifically was not discussed, there was some talk about more specific exceptions.

SPL exceptions shouldn’t be thrown from ext/standard. If that’s the blocker, I’d rather see it resolved

Yes, the SPL exceptions are now of limited use and partially overlap with other things such as ValueError. I would think there would already be an exception I could reuse for the simple case where an argument cannot be processed, but apparently not. The transitions to namespaces and exceptions just has not progressed that far. If you have any suggestion to improve the situation, please let us know.

Regards,

Sjoerd

#externals

[VOTE] [RFC] Case-insensitive extension names in ini_get_all()

[RFC] [VOTE] Throw exception for invalid characters in number base functions

[RFC] PDO binary parameter support

[RFC] Scope

[RFC] Scope

[RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

Request for RFC karma

RFC karma request: grapheme_str_pad()

[VOTE] [RFC] Case-insensitive extension names in ini_get_all()

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Best,

[RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

[RFC] Opt-in JSON Comments and Trailing Commas

[RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

GitHub access request

[RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

[RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Best,

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

RFC karma request: grapheme_str_pad()

[Meta] This Week In PHP Internals | October 29, 2026

[RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

[RFC] openssl_get_channel_binding

[RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Best,

[RFC] CSV Extension (ext/csv)

[RFC] CSV Extension (ext/csv)

[RFC] CSV Extension (ext/csv)

Six functions and one class in the Csv\ namespace.

RFC 4180-compatible parsing and serialization by default.

Locale-independent processing without the proprietary escape mechanism.

Multibyte delimiters, enclosures, and EOL sequences.

Strict and lax collection parsing.

Hence why I believe that using terms like lax and strict is counter productive; probably other names "to be defined" should be used instead. Maybe adding an Enum With RFC4180 and something else (?) would be a better take. Which would reduce the number of function/methods introduced ?

PHP 8.4.27 configure writes to read-only source tree but exits successfully

SSRF protection in curl

[RFC] Time\Instant and Time\Clock

[RFC] Time\Instant and Time\Clock

[RFC] Scope

[RFC] Scope

[RFC] Scope

Proposal for Discussion: Effect Declarations and Capability-Gated Process Execution in PHP

Proposal for Discussion: Effect Declarations and Capability-Gated Process Execution in PHP

[RFC] openssl_get_channel_binding

[RFC] array_partition()

[RFC] array_partition()

[RFC] [Discussion] Query Parameter Manipulation Support

[RFC] array_partition()

Proposal for Discussion: Effect Declarations and Capability-Gated Process Execution in PHP

Whether effects should be explicitly declared, inferred, or support both approaches.

How effects should propagate through function calls, closures, dynamic calls, and third-party dependencies.

How parameterized effects should be represented and validated.

Whether effect contracts should be enforced by the PHP engine, external static analysis tools, or a combination of both.

How effects could integrate with runtime capabilities and existing APIs.

[RFC] openssl_get_channel_binding

[RFC] CSV Extension (ext/csv)

[RFC Idea] Formalization moratorium after PHP2Shell (CVE-2026-109618/109619): independent implementations in Rocq/Agda/K/Redex

[RFC] array_partition()

[RFC] CSV Extension (ext/csv)

Proposal for Discussion: Effect Declarations and Capability-Gated Process Execution in PHP

[IDEA] Native async/await syntax on top of Fibers

[RFC] Scope

Updated PHP Windows builds for Brotli security fix

[RFC] CSV Extension (ext/csv)

Six functions and one class in the Csv\ namespace.

RFC 4180-compatible parsing and serialization by default.

Locale-independent processing without the proprietary escape mechanism.

Multibyte delimiters, enclosures, and EOL sequences.

Strict and lax collection parsing.

[RFC] array_partition()

Proposal for Discussion: Effect Declarations and Capability-Gated Process Execution in PHP

Whether effects should be explicitly declared, inferred, or support both approaches.

How effects should propagate through function calls, closures, dynamic calls, and third-party dependencies.

Hence why I believe that using terms like lax and strict is counter
productive; probably other names "to be defined" should be used instead.
Maybe adding an Enum With RFC4180 and something else (?) would be a better
take. Which would reduce the number of function/methods introduced ?

Whether effects should be explicitly declared, inferred, or support
both approaches.

How effects should propagate through function calls, closures, dynamic
calls, and third-party dependencies.

Whether effect contracts should be enforced by the PHP engine,
external static analysis tools, or a combination of both.

How effects could integrate with runtime capabilities and existing
APIs.

Locale-independent processing without the proprietary escape
mechanism.

Whether effects should be explicitly declared, inferred, or support
both approaches.

How effects should propagate through function calls, closures, dynamic
calls, and third-party dependencies.

Whether effect contracts should be enforced by the PHP engine,
external static analysis tools, or a combination of both.

How effects could integrate with runtime capabilities and existing
APIs.

Whether effects should be explicitly declared, inferred, or support both
approaches.

How effects should propagate through function calls, closures, dynamic
calls, and third-party dependencies.

Whether effect contracts should be enforced by the PHP engine, external
static analysis tools, or a combination of both.