[PHP-DEV] PHP 8.1.28 Released!

[Ben Ramsey]

The PHP development team announces the immediate availability of PHP
8.1.28. This is a security release that addresses CVE-2024-1874,
CVE-2024-2756 and CVE-2024-3096.

All PHP 8.1 users are encouraged to upgrade to this version.

For source downloads of PHP 8.1.28 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: 
Downloads:
Windows downloads:
Changelog:
Release Manifest:


Many thanks to all the contributors and supporters!

Ben Ramsey, Patrick Allaert, & Joe Watkins



php-8.1.28.tar.bz2
SHA256 hash: 
8be450096e0153c47d75384e7dd595cc897f1d53ce0060708ce9589bcc3141ee

PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEObZBND2MEEsrFG3D+cOdwLlphUQFAmYWKhEACgkQ+cOdwLlp
hUSOdQ/6A4kNhmwxtlmgV2HTRdQ5niUYFVTOLs2vdE/lc6fDHfQgsrXaiV+1LlKy
6tKCE8ki9t7rLABDQxqdkVlCK1WRpgDtFZCIxb5FVoWOuhbMLJsIf3FDTAkVmnrn
aU6k+K5NKi3lMYer9pKCjB7PKffMpLWps1PImMf7RQ7baLirNl0wH1DMfPBd+FLr
nvKC3TE8XohATjgveMT9omBzyqvLmQ7fQwYJLPZJypuiQAXf+zGGh82D1XGJArq0
2T4l/u6SmrOOG/8RXX4MAhsTMZ6GdTWmQZiHBi7d2EULvJkgXg12mUweQ/adJs1W
if+1IiNvAc5VdbURebunVpNExyOE1MrTvKWKdHBY3vJPeTrR+CL1zD9/ho3TSyKi
JnnUnNAhF2WXWW7jJkqyEV1pJYkhgf7YREKXrp/WSEUzOfLr0tI4qxGAkOSdZpeW
55FJsK5bkKB0g5sL2FJi153Ln5RbNctd3T3AUhQuHsuuVE2QX42HBetPVman7gwO
bspXAM3RATJvC26HlOwXxs4fxFPIkhVw3V9wk/Od6UQDZ/4gKGedBQuZu5gFBzOA
6ReIdX5Og8xx+9PFMlRl6CGGhipq7+igEsJSSUnwakZhlbIvbSBrjIm168KUB1EM
7WDmf4/lsNCi3ixJ1RgNj3ILVJhH6XIr6sw1gDOctY4rZafb+Ww=
=ygnC
-END PGP SIGNATURE-


php-8.1.28.tar.gz
SHA256 hash: 
a2a9d853f4a4c9ff8631da5dc3a6cec5ab083ef37a214877b0240dcfcdfdefea

PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEObZBND2MEEsrFG3D+cOdwLlphUQFAmYWKhEACgkQ+cOdwLlp
hUS7axAAsn3G3vPgtTygPioOqIHci/9p98+xSqk1t64rdHMuYwVIShlDLk0QlReM
Fpq5Q3Gn4b1e7qrQWnY7tyMJkTdJGoh4dRTHI7y9J+nVjAYC8Mll/fLKgW5q+HzV
EAe1mnF2S+Mk+WcyJuDybVEy4S2lHHoCSsVBQX9BNyYJA958VzTvFyLcuU0o2Md3
mcEWNYOyqZN0SbZaD7+W274vb2txYuWPOch2yO7c6LwfV1Dcef9Lqr0LOiS6t43g
wc0QqzK9fEdXGtNpNyPR3EgwLvOlsDfGg6SrQQ7JgZ7QoXKE3MzxMwjq4bEDN672
36pg4QV12ivBQX0Oa21wV2ZFfRlDd5LgrE1bdqY13lXyPseHzi8T3BBJ11fx9rZw
xQSaaBBFV3PX7+VH1qZYVukLEzkbTom3z7HODR76SYw/S5n2Gk48hIsPqBDJ8P5g
TjQZ74Ia4e8N7RZxwBwJZjT2mwn3FA05XZESSS0gPOnYqoY5p0/Z/e4qDSuwxhOH
i/ChC22gYBa3AkNxYHpW4NmFJv0BeNUTIJ7WPPNPAkvcwfGpBqUh1CVuKEGbfc+u
wp4bNjN3GpBz8rJj9tG5kSp7CSHfw1F6B6Tb+hHd2voq7WjprB4vTa5zZgZIbH8t
KB2jHw+S/Ro/5NYzRGC47hU2hrdu7wy6X4G0IPPLLPoI84LnbE0=
=vCxL
-END PGP SIGNATURE-


php-8.1.28.tar.xz
SHA256 hash: 
95d0b2e9466108fd750dab5c30a09e5c67f5ad2cb3b1ffb3625a038a755ad080

PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEObZBND2MEEsrFG3D+cOdwLlphUQFAmYWKhEACgkQ+cOdwLlp
hUT1Pw/+LcTKGIyVNKJNhpk5uyQXrXmd/5hKbHdPw7Sl6OmghVveEhBm/R3kuQv0
8XvQ6/egdJGYVg7gVjAhIztfuZHjj5/4Se7wX9mMs+Agdh5/tobA7f1V5N4ft8RE
O2m6lFICtlbodJl1TEZYNkqOk8nQP+DQKuX/vJU96x+I0e3FDEaFmkgsSTuHboiw
VoOX2bSXYmaETNJ3cEbhirTQyRb31geXw+mwuYjEvlNg2UGwMj85mXSYmd1+T7jU
Dv3ZbVaMjsRi63K73YDKCUMI30k0FlvG51HYW+4tm3l+W9Y3bjTEfpfF+7Oy6uW7
K/Qb/Cq1haQPj0VKzxabFnfoIoQyHlbiFPFs05pLRpM4QegvLne0ma1Ec9eOGVUe
4FNSkhnP5WFj5mwErory4BaFq9xk9TjfMSu/jLzBRXwQZWFL5hoejD0A2FzETU4x
t0/Rb3/sKRK4imZkogLnDIx7ae5FZ5exAn6sZjFg5bwd95kHwVOzT+9sOiMWAYhH
YAE5zKd6zUr7RBzuAd9okXebELdnMxEjfvVb2Ew/14E4fxHbznD3VjEEyMsF3R85
1jPM6rYCWPXptM4AeCd/HJzCnHs5KFqNjn6FZ1yCHCW3fyLd52lhqcFMc4cRI5Aw
xJpwdMU0TvqBV8YE0rUUURvcFT9l7ArB8dBE/vHKzIZeqhK8fSI=
=jB34
-END PGP SIGNATURE-


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Larry Garfield]

On Fri, Apr 12, 2024, at 2:55 AM, Juliette Reinders Folmer wrote:

> The first part of my email (up to the "Furthermore") was mostly me 
> trying to summarize the complexity of the proposal and to compare it to 
> existing syntaxes and list those things which - to me - appeared 
> inconsistent with other PHP features. It was not intended as criticism 
> on individual choices made and I'm not sure whether, if I were 
> designing this feature, I would have made different choices, other than 
> to have just one syntax - the "full" syntax (with a `get();`/`set();` 
> variant - yes, always with parentheses - for abstract/interface 
> properties).
>
> This first part was meant as a summation to highlight how incredibly 
> complex this new feature is and how many opportunities it offers 
> developers to shoot themselves in the foot.
> Let alone, how many problems this can cause when developers use classes 
> in dependencies which use this new feature and they have limited to no 
> awareness of whether they are using virtual or backed properties on the 
> dependency.

The RFC itself is complex because PHP is complex, and the problem space is 
complex.  For instance, when hooks exist, what does that do for the return 
value of `=`?  Most devs probably don't even remember that there is one, but as 
a language design element it has to be considered.

Overall, the guiding design principle for this RFC was to make it as 
transparent as possible, so that devs who "use classes in dependencies which 
use this new feature and they have limited to no awareness of whether they are 
using virtual or backed properties on the dependency" do not need to care.  The 
whole point is that it should be a transparent change, or as transparent as 
possible.  Most of the complexity of the RFC is figuring out what the most 
transparent behavior would be, and ensuring that works.

As indicated in the introduction, a primary use case for hooks is to not need 
to use them at all; 90%+ of all Doctrine entities I've seen have dumb 
boilerplate do-nothing get/set methods, placed there as a "just in case we need 
it" or "because That's How It's Done In Java Beans."  Occasionally they do a 
little extra set validation, but not in the majority case.

Hooks allow eliminating that "just in case" boilerplate.  If hooks get almost 
no usage in the wild, but the option to use them eliminates hundreds of 
thousands of lines of effectively no-op getX() methods, I will consider it a 
resounding success.

> As the proposal purports to be a better alternative to the magic 
> `_get()`/`__set()` methods, I would expect it to prevent a lot of the 
> problems associated with those methods. However, what I found - and 
> what you seemingly confirmed in your reply - is that this new feature 
> does *not* in actual fact solve the problems magic methods have. It has 
> the same problems + more problems associated with the new feature 
> itself.
>
> Part of my concern is therefore that this feature adds significant 
> extra complexity to the engine, for little to no real benefit, other 
> than to have a nicer syntax for creating the same problems we already 
> had before.

I believe this is a highly disingenuous description of the RFC.

* Hooks are automatically static-analysis-friendly.  __get is not.
* Hooks are automatically IDE autocomplete-friendly.  __get is not.
* Hooks provide built-in type enforcement.  __get does not.
* Hooks allow properties to be self-documenting.  __get does not.
* Hooks avoid smooshing multiple different virtual properties into a single 
mega-method.  __get requires that.
* Hooks allow opting-in to reference semantics per-property.  __get is 
all-or-nothing.
* Hooks have clear, consistent integration with serialization (in that the 
behavior with each serialization mechanism is consistent with that mechanism's 
expectations).  __get doesn't interact with serialization at all, leaving you 
to do everything manually.
* Hooks allow properties to be declared without special behavior, and add 
special behavior later without a BC break.  __get... only kinda sorta does 
that, if you use it just right.
* Hooks cleanly allow pre-defining properties to get the substantial memory 
savings of well-defined properties.  __get may or may not, depending on how you 
impelement it.

>From a usability perspective, hooks are vastly superior to using __get/__set 
>directly.

However, both __get/__set and hooks operate in the same problem space: 
Inserting extra user-space code in between what otherwise seems like a boring 
variable read/write.  *That* concept naturally involves complexity, by 
definition, and has lots of edge cases, by definition.  Any attempt to insert 
user-space code into that operation would run into the exact same set of 
complexities; References exist, we have to deal with them somehow.  `=` 
evaluates to a value, we have to deal with that somehow.  Inheritance exists, 
we have to deal with that somehow.  isset() exists, we have to 

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

[Saki Takamachi]

Hi Gina,

> This isn't a BC Break in theory as class names are, for the time being, 
> case-insensitive.

Strictly speaking, this can be considered a BC Break because the string 
returned by `::class` changes.
However, I'm not sure how much of an impact it will have.

Regards,

Saki

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Rowan Tommins [IMSoP]]

On 10 April 2024 04:40:13 BST, Juliette Reinders Folmer 
 wrote:

* Whether a type can be specified on the parameter on `set` depends on whether 
the property is typed. You cannot declare `set(mixed $value)` for an untyped 
property, even though it would effectively be compatible. This is inconsistent 
with the behaviour for, for instance method overloads, where this is 
acceptable: https://3v4l.org/hbCor/rfc#vrfc.property-hooks , though it is 
consistent with the behaviour of property overloads, where this is not 
acceptable: https://3v4l.org/seDWM (anyone up for an RFC to fix this 
inconsistency ?)



Just picking up on this point, because it's a bit of a tangle: PHP currently 
makes a hard distinction between "typed properties" and "untyped properties". 
For instance, unset() works differently, and the "readonly" attribute can only 
be added to a typed property.

That's actually rather relevant to your point, because if this RFC passes we 
would probably need to consider that PHP has at least 4 types of properties: 

- dynamic properties (deprecated by default, but allowed with an attribute)
- declared but untyped properties
- typed properties
- virtual properties

But maybe 6, with: 

- untyped properties with hooks
- typed properties with hooks

Of course, most of the time, users aren't aware of the current 3-way split, and 
they won't need to think about all 6 of these variations. But there are going 
to be cases where documentation or a future RFC has to cover edge cases of each.

I do think there is scope for removing some features from the RFC which are 
nice but not essential, and reducing these combinations. For instance, if we 
limit the access to the underlying property, we might be able to treat "virtual 
properties" as just an optimisation: the engine doesn't allocate a property it 
knows will never be accessed, and accesses to it, e.g. via reflection, just 
return "uninitialized".

I am however conscious that RFCs have failed in the past for being "not 
complete enough" as well as for being "too complex".

Regards,
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

[Gina P. Banyard]

On Friday, 5 April 2024 at 18:00, Tim Düsterhus  wrote:

> Hi
> 
> I've just written up the follow-up RFC to my previous “Casing of
> acronyms in class and method names” thread and I'm officially opening up
> the discussion period for it.
> 
> Please find the following links for your convenience:
> 
> RFC: https://wiki.php.net/rfc/class-naming-acronyms
> Previous ML discussion: https://externals.io/message/120959#120959
> Related discussion in PHP-FIG:
> https://github.com/php-fig/per-coding-style/issues/83
> 


Thank you for working on this!

I agree that this policy change makes sense.

I was wondering, however, if there should be a follow-up RFC to normalize the 
casing of existing classes?
This isn't a BC Break in theory as class names are, for the time being, 
case-insensitive.
I know in practice that tooling in the ecosystem normalize the names to be the 
one as currently defined, so it might produce diffs depending on which version 
of PHP the tool is ran on.
The output of tests could be affected.

Maybe this change is better suited for PHP 9?


Best regards,

Gina P. Banyard

Re: [PHP-DEV][DISCUSSION] Fix mb_trim inaccurate $character

[Nicolas Grekas]

Hi

Le jeu. 4 avr. 2024 à 07:41, youkidearitai  a
écrit :

> 2024年4月4日(木) 6:30 Tim Düsterhus :
> >
> > Hi
> >
> > On 4/3/24 10:02, youkidearitai wrote:
> > > Therefore, I think require an RFC, I have written a draft an RFC that
> > > fixes these issues.
> > > https://wiki.php.net/rfc/mb_trim_change_characters
> >
> > I don't think this (widening the type and changing the default value to
> > obtain the *intended* behavior) requires an RFC. It's a bugfix, a bugfix
> > with a slightly larger observable impact than other bugfixes.
> >
> > Best regards
> > Tim Düsterhus
>
> Hi
> Thank you very much for comment.
>
> I would like to discuss this RFC with all of you, as we have not yet
> decided on the correct revision policy.
> I created the RFC for that purpose.
>
> Still waiting for your comments!
> Thank you.
>
>
I also don't think this requires an RFC. This is a minor design issue that
has only one possible solution, so there is little to discuss.

Cheers,
Nicolas

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Marc Bennewitz]

Hi,

On 12.04.24 04:55, Juliette Reinders Folmer wrote:

Hi Ilija,

On 12-4-2024 1:00, Ilija Tovilo wrote:



Oh, and hang on, they *can* be read from a method in the same class as long as 
that method is called from within the set hook, so now the method will need to 
either do a backtrace or use Reflection to figure out whether it has access to 
the property value.

Right. We use the same mechanism as `__get`/`__set` uses to protect
against recursion. In particular, when entering a magic method for a
particular property, PHP remembers this using a "property guard". It's
really just a marker in the object that sets the magic method type,
along with the property name.

When the same property is accessed again, the magic method or hook is
skipped, and PHP behaves as if the magic method or hook wasn't there
at all. For `__get`, `__set` and hooks of virtual properties, this
means accessing a dynamic property. For backed properties, this means
accessing its backing value.

After discussing it, we've decided to make virtual properties slightly
less surprising by throwing, instead of trying to create a dynamic
property. This would be consistent with how virtual read-, and
write-only properties are handled outside of hooks, when they are
written to or read, respectively.


Forgive me, but I had to chuckle at the mention of virtual properties 
needing to access a dynamic property in the context of a property guard.
My thoughts went straight to the following question "Does this mean 
that support for dynamic properties could never be removed if this RFC 
gets voted in ? And if so, can we please get rid of the deprecation 
notice (and need for the attribute) ?"


But I see you've already answered that question by changing the 
behaviour to throw now. ;-)


This was something I was confused by as well but wasn't sure at all if 
this would actually be an issue in a real world. So I tried to come up 
with a real world example.


If I understand correctly you already changed the behavior to throw now 
but I still want to share anyway 


Imaging, as library author, you have a property with hooks that contain 
a typo and you want to rename it in a BC way. Let's say you want to 
rename "oldProp" to "newProp" but both should work the same as if it 
would be the same property.


class Test {
    const PREFIX = 'backed:';

    public string $newProp {
    set => $this->prefixize($value);
    get => $this->getProp();
    }

    public string $oldProp {
    set {
    $this->newProp = $value;
    }
    get => $this->getProp();
    }

    /** Complex value transformer */
private function prefixize($value) {
    return self::PREFIX . $value;
    }

    /** Complex value reverse transformer */
private function unprefixize($prefixed) {
    return substr($prefixed, strlen(self::PREFIX));
    }

    private function getProp() {
    return $this->unprefixize($this->newProp);
    }
}

$t = new Test();
$t->newProp = 'foo';
var_dump($t); // object(Test)#1 (1) { ["newProp"]=> string(10) 
"backed:foo" }

var_dump($t->newProp); // string(3) "foo"
var_dump($t->oldProp); // string(0) ""

$t->oldProp = 'bar';
var_dump($t); // { ["newProp"]=> string(10) "backed:bar" }
var_dump($t->newProp); // string(3) "bar"
var_dump($t->oldProp); // string(0) ""


Kind regards,
Marc


OpenPGP_0x3936ABF753BC88CE.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature