[PHP-DEV] Straw poll: Interest in configurable callback to dump results of expressions in ''php -a''

[tyson andre]

Hi internals,

I've started a straw poll 
https://wiki.php.net/rfc/readline_interactive_shell_result_function_straw_poll 
after feedback on the RFC: https://externals.io/message/112568#112737
Notably, there was discussion of whether it made sense to provide the ability 
to dump expression results without doing it by default,
as well as whether php should go in a different direction to make it easier for 
userland shells to replace `php -a` instead.

Voting on the straw poll starts today and ends 2021-01-14

Thanks,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Array unpacking with string keys

[tyson andre]

Hi Nikita,

> I'd like to propose that string keys be allowed when unpacking into arrays:
> https://wiki.php.net/rfc/array_unpacking_string_keys
>
> Especially as unpacking in calls supports string keys now, I believe it is
> time to drop this limitation for arrays as well.

+1, was considering proposing the same array_merge semantics as this RFC
but didn't get around to looking into why this wasn't in the original php 7.4 
array unpacking RFC.

Regards,
Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Are there plans for ending support for 32-bit php? (year 2038 problem)

[tyson andre]

Hi internals,

1. In 2038, `(new DateTime())->getTimestamp()` and other time apis such as 
strtotime will start throwing "ValueError: Epoch doesn't fit in a PHP integer"
   on 32-bit php builds, where PHP's `int` type is 32-bits.
   (other APIs will return negative 32-bit integers)
   See https://en.wikipedia.org/wiki/Year_2038_problem
2. Because PHP provides security support for 3 years, and many `*nix` OS LTS 
releases extend it even longer, we should decide on what to do about
   32-bit support well before 2038 (drop it or implement alternatives, and 
alternatives seem unlikely to support a small fraction of hardware).
3. Needing to support 32-bit PHP builds limits the APIs that can be included in 
PHP, and slightly slows down development of PHP, PECLs, and composer packages.
4. I think PHP's documentation and tools should start discouraging deploying 
new 32-bit builds, and give advance notice that it would be removed (if it 
seems likely 32-bit support will be dropped.)

Repeating the above points in more detail,

1) In the year 2038, many of 32-bit php builds' APIs dealing with unix 
timestamps will stop working.
E.g. in 2038 on a 32-bit build of php, `(new DateTime())->getTimestamp()` would 
throw "ValueError: Epoch doesn't fit in a PHP integer" instead of returning an 
int,
when the time passes 0x7FFF. See https://bugs.php.net/bug.php?id=52062 for 
details.
I'd consider throwing in getTimestamp to be the most reasonable solution, given 
the return type of those methods is `int`, existing code may pass the return 
value
to a function/property with real type int, etc.

- https://www.drupal.org/docs/system-requirements/limitations-of-32-bit-php

2) Although php's security support for a minor release lasts for only 3 years,
some `*nix` OSes will make a best effort at unofficially backporting patches to 
php for the lifetime of that OS's LTS release,
so we could potentially see 32-bit builds for ~10 years (not sure what 32-bit 
distros there will be in 2028. This number is a guess.)
- on **desktop** oses, the main use of 32-bit packages on 64-bit hardware seems 
to be for supporting code released for only one architecture,
  e.g. 
https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts
- Many WordPress servers still run php 5.x.
- If applications running on an OS with 10 years of php support computed dates 
that are a year in the future,
  it'd be useful to prepare 11 years in advance.
  There are 17 years until 2038.

Hardware that only has 32-bit support is still running on a small fraction of 
machines being sold (e.g. cheap laptops),
and 32-bit hardware may last decades after they were manufactured,
but is hopefully a tiny fraction of server/consumer hardware still being 
manufactured in 2021.
I don't know of 32-bit php running in embedded systems or IoT devices, but 
haven't looked.
- Aside: It is possible to install a 32-bit only OS on hardware supporting 
64-bit architectures, https://www.backblaze.com/blog/64-bit-os-vs-32-bit-os/

If PHP's maintainers decide to drop support for 32-bit builds in a future 
major/minor release, it would be useful to give users advance notice,
so that they can factor this into decisions on hardware and OSes to use for 
deploying php in servers or developing locally.

3) Needing to support 32-bit PHP builds limits what can be done in the 
language, and slightly slows down development of PHP, PECLs, and composer 
packages.

Additionally, continuing to provide 32-bit support constrains what APIs can be 
provided by the language.
In most cases this isn't an issue, but this came up with `PRNG->next64BitInt()` 
being impractical practical in a recent proposal: 
https://externals.io/message/112525#112722

- 32-bit installations do reduce the memory usage and installation size of php 
slightly,
  but those installations would have problems with the 2038 problem and 
supporting use cases that require more than 2-4GB of free memory.
- PECLs and composer packages are generally not tested as thoroughly on 32-bit 
builds.
  Maintainers may be less responsive if they're personally unaffected, or don't 
already have 32-bit builds installed, or don't know from the bug report that 
32-bit php was used.
- The PHP interpreter (Zend/zend_vm_def.h, etc.) and JIT have different 
implementations for 32-bit builds, complicating development of php itself.
  Hypothetically that could lead to bugs getting released and contributing to 
the VM being harder to do, but in practice it doesn't seem to be a large issue.

In comparison, other languages I've used would have an easier time continuing 
to support 32-bit builds past 2038.

- Python and Ruby have arbitrary-precision numbers.
- In Java, `int` is 32-bit, and `long` is 64-bit.
- Golang and C and rust have `int64_t` and `int32_t` equivalents, but also 
support a separate `int` for the native word size.
- Javascript only has a `Number` type that is equivalent to 64-bit floats. JS 
also has a distinct BigInt

Re: [PHP-DEV] Re: [RFC] Phasing out Serializable

[Björn Larsson]

Den 2021-01-06 kl. 17:51, skrev Nikita Popov:

On Tue, Dec 15, 2020 at 12:14 AM Björn Larsson 
mailto:bjorn.x.lars...@telia.com>> wrote:


Den 2020-12-07 kl. 16:49, skrev Nikita Popov:
> On Mon, Dec 7, 2020 at 3:49 PM Björn Larsson
mailto:bjorn.x.lars...@telia.com>>
> wrote:
>
>> Den 2020-12-07 kl. 15:11, skrev Nikita Popov:
>>
>>> Hi internals,
>>>
>>> Picking up a loose thread:
>>> https://wiki.php.net/rfc/custom_object_serialization
 introduced a
>>> replacement for Serializable in PHP 7.4, so it's time to think
about
>>> deprecating and removing the old mechanism:
>>>
>>> https://wiki.php.net/rfc/phase_out_serializable

>>>
>>> This RFC follows a rather conversative approach. In PHP 8.1
there will
>> be a
>>> deprecation warning if Serializable is implemented without also
>>> implementing __serialize() and __unserialize(). In PHP 9.0,
support for
>>> Serializable is dropped internally, and only the interface
retained. In
>> PHP
>>> 10.0 the interface is dropped as well.
>>>
>>> Regards,
>>> Nikita
>>
>
> I had to slightly extend this RFC to also deprecate & remove the
> PDO::FETCH_SERIALIZE mode, which is based on Serializable.
Doesn't seem to
> be a big loss, as this fetch mode isn't working correctly in the
first
> place...
>
>
>> Given that 10.0 lies maybe ten years in the future if we have a
similar
>> timeline >> like for 7.0 to 8.0. Is it then realistic to have
such a
>> long-term planning? For me it feels a bit more prudent to remove it
>> completely in 9.0.
>>
>> Otherwise +1!
>>
>
> I'd be also okay with dropping it entirely in PHP 9. That would
mean that
> there is no prior deprecation warning if you implement it
together with
> __serialize() and __unserialize() though, which is why I went
with the
> proposed timeline. From my own (technical) perspective, the case
is closed
> in PHP 9 either way, because that's where we can rip out support in
> unserialize().
>
> Nikita
>
Not sure I understand why no deprecation warning is needed in 8.1,
if removing completely in 9.0?

The current proposed timeline only removes in PHP 9.0 what was 
deprecated in PHP 8.1. Possibly I'm misunderstanding what you have in 
mind here.


Ok, then I read it wrong, completely fine with above.


Anyway, my main objection towards the proposed timeline is not so
much about the functionality removed. It's more related with that
I think an RFC that mandates what should happen in 10.0, maybe
10 years into the future feels a bit farfetched.

Of course there could be exceptions for RFC's targeting PHP 10.0,
but then I think it should be for something big, like replacing
the SPL library etc.


I'm not sure I understand what your actual concern here is. Yes, it's 
a long-term plan, but why is that a problem? Why should long-term 
planning only be limited to major changes? Even a simple deprecation 
already works on a 5 year timeline, between deprecation and removal. 
Of course, I have no idea whether I'll still be involved with the PHP 
project in ten years time, but I suspect there will always be someone 
who enjoys deleting deprecated code to carry out the will ;)



Not sure we had RFC's earlier with a ten year lifespan. So I have
a concern about how realistic it would be ;-) The RFC is targetting
two major versions, think it would be cleaner to target only one
of them, not two.

Now we have this RFC for 8.1 and we remove it it in the first step in
9.0 followed by removing it completely in 10.0. One motive for this
as I understand it, is the <7.4 support.

Anyway, come to think on the RFC "Remove PHP 4 Constructors"
which targeted 7.0 and then it was removed completely in 8.0.
Also thinking on the 7.4 deprecation RFC, where the items was
removed in 8.0.

So is it by having this RFC targeting 8.1, we get five extra years
or is it the <7.4 support?

r//Björn L

Re: [PHP-DEV] [RFC] Array unpacking with string keys

[Kalle Sommer Nielsen]

Den tor. 7. jan. 2021 kl. 21.19 skrev Larry Garfield :
> Hard yes.  I ran into a case just yesterday (while doing some sample code for 
> immutability) when I wanted to merge associative arrays this way and the 
> alternate was much yuckier.

Seconded, I ran into a similar thing yesterday and it took me a bit to
figure out what was going on. This RFC would fix that behavior so big
+1

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Array unpacking with string keys

[Larry Garfield]

On Thu, Jan 7, 2021, at 5:30 AM, Nikita Popov wrote:
> Hi internals,
> 
> I'd like to propose that string keys be allowed when unpacking into arrays:
> https://wiki.php.net/rfc/array_unpacking_string_keys
> 
> Especially as unpacking in calls supports string keys now, I believe it is
> time to drop this limitation for arrays as well.
> 
> Regards,
> Nikita

Hard yes.  I ran into a case just yesterday (while doing some sample code for 
immutability) when I wanted to merge associative arrays this way and the 
alternate was much yuckier.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8.0.1 Released!

[Patrick ALLAERT]

Hi Gabriel,

I can see that https://bugs.php.net/bug.php?id=80426 isn't part of
the ChangeLog while I'm pretty sure it is fixed in that release.

Not that I care about that one in particular, but maybe that isn't the only
one missing there.

Cheers,
Patrick

Le jeu. 7 janv. 2021 à 17:44, Gabriel Caruso  a
écrit :

> The PHP development team announces the immediate availability of PHP
> 8.0.1. This is a security release.
>
> All PHP 8.0 users are encouraged to upgrade to this version.
>
> For source downloads of PHP 8.0.1 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:
>
> Many thanks to all the contributors and supporters!
>
> Sara Golemon and Gabriel Caruso
>
> Release Manifest here and below:
> https://gist.github.com/carusogabriel/277fa09acd2734ec009294990b8d1f6e
>
> php-8.0.1.tar.gz
> SHA256 hash:
> f1fee0429aa2cce6bc5df5d7e65386e266b0aab8a5fad7882d10eb833d2f5376
> PGP signature:
> -BEGIN PGP SIGNATURE-
>
> iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl/0cUEWHGNhcnVzb2dh
> YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj5inD/9lbPqTb4709RQIMBGB2PK5HV4C
> 4oWKaiWy2S0jm9cKwvUqprDJTlKZXglnJC/nJc8oXyekGM5NkuD+lc6FwQvzSA/n
> 1yXV3aeELy1xG6AvLMTJz8pk9a1peBrpJ6xHtFNI1mPAD93OvE2hoXk6w27UT2eA
> i/kM1EI+I6bMUoPwwjk1PTPI7TaIu4FTZbNjxGlU7bcaDMDwgBtQhCPgEq/NbnnC
> XW5i4GAMzst7kbsiC3hKs/zew7oh2Yjc7pW5irtplTtL+86CePeu6k6+1Ff0+iA3
> 61YGjvCLo+PCEzeKyfYfuUZ0Tz3qYGC9/TPx38Tk908EQ32bkeG7/p6uUdg96IWV
> l/HN7YcaIA/yo/NMeYvhjKlAFPv3Elo2ZHuhucmAsBQ7CIu3V6Jd43dUpmXAe2PH
> Uf4Rxsbvf0TRp2Xja5I+alopLLBceMM6WALVuvdnPhUhgNLoeM3VPijgmkZT1toW
> a6pKCg38PwPwSdA6eLeJ9qBz0H8iPUSGS8EuFcB/CbGuw0eJw0yAf990LPttIkca
> JJXuhVxBSrSzHL56WvoQ/gxRrf6dK2VfpbS3cjnInXffaI/JykIGiDhfWaIBTxzN
> tcyQSEBegTPHtT9PehpxsfO2gKdeQQX+np9a/p0S05tuGsNkjIYFK0lggnwnza+J
> oUwxe5oSYVh1DNtMpQ==
> =p4/f
> -END PGP SIGNATURE-
>
> php-8.0.1.tar.bz2
> SHA256 hash:
> c44e76af40d133de64564f9caf5daec52bbe84c1ccb4e4500a62233d614ebdee
> PGP signature:
> -BEGIN PGP SIGNATURE-
>
> iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl/0cUIWHGNhcnVzb2dh
> YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj//eEADEMSfKUUnORTy+RuDBiA/XB9l0
> +xk98qG6uyZ2mRv04XjP/qTks1NvY5P6gcjeU5NCUaxMZY4B1grVQECuHnuZx1oR
> XZtKRfLpFxN+c5MOQ3zU6We07jWQSJ5827UWPOZlEKvYM7Ta85o2Q6aUwzvHwM9l
> E6er6iz2tlLxtgwNYsGfaqMWOSfQP/JjNWHxmSocthtV78g5jum1uc6i87uHOqeO
> xZmjpIGCYadXWfd++5xyLzSxlrlV/3sWSFSMNHGytO/R/YgXnpzqnnZK20uFDC7U
> 3O+C3IPGUr7LUUhJmJz2nCoaO9aLXAQpf4Hf/AzykTksk4u90UIMNf3zHa38b82I
> +XWTQ061uUyjL1DVOPFWNtpOLrRJSzk4i5M+VPIOW8+c7FwSdMYI6dHsSqyWIJ+C
> eLFwEDrRj9SwuOurNTdML6knoJqvJcGm9Q+IzEwIjFyM1X9cLpnARk/Jeqf1d65C
> KMsg6BaDLjQASx3AO+u3uMDs8Qo7zNZjQqbMLk0JjrY/n0ACw5oQM6RdbEsfokRE
> kQywZ0bNTOM+jQIAgfCyQSc+PyTUE4TjstZpk+TVdVQ02xdKpqGPDCANv4eP3joy
> 2qCwLSWZRlbyT+1QH0LpnXR+n5VNetrVPjJsU1rD7/dIOYmWXC7WV59A6mEtzr93
> ThdYSpAaIShl7imPxg==
> =SnRb
> -END PGP SIGNATURE-
>
> php-8.0.1.tar.xz
> SHA256 hash:
> 208b3330af881b44a6a8c6858d569c72db78dab97810332978cc65206b0ec2dc
> PGP signature:
> -BEGIN PGP SIGNATURE-
>
> iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl/0cUIWHGNhcnVzb2dh
> YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRjy+jD/914syanckmQVEmVHQs1NQWqv7b
> IG4UoN0wdAu44Ks4YC0vRaS3D8BYbZJ4FpZrYRElMupsJqgDhFNAMtv+YIEOMxzc
> RuQQAALsBZI5U+5OUP8e12GmprXo8Nm4ppxlAW+/WXOQO/UqWPmlR4KVD+KAAmw/
> dnKDx6G+MFKK0i/HvPk8vOkcBXkaJ6mrVpb4oeolSmKBUFuBW2ercQZbotlYv19l
> riP5o2Rar71m3qt8HJUBAQgqVAnEjYZQJGy37WceQ6jyHsTpiYmWPlVqZfy0bY4F
> uxMkPf+d3bmIJhhHwyi3Z/SJMq7y3XbQiLAAgjBHhKuDX/LJxO6EAvDceGX0Ptdz
> i9j1Z6i30SDAdQC43jv7uYTuonwySzM9bUKh0py2lOe5GAMORVTQ9oez4OD7tN6R
> zkGL0IgbCtWkpdB6zayT2aHl5B0voz2a4OPy5P1Z+RynnWndvDAID+IPMeqTDIVY
> KPdwYUwCPJAliR/f7MBfJUkVZ4IYvAO6sIOg23yGQyE039l18jtDHYQ0r2D/KIc5
> /6h7Eo9uc+JoAJayvdTUB+xxVZx1dwusUo4Icm2UWXtVynyX8Rt8Oavn/V4Ox1bo
> 5r25DW2tOrjKoM80FcPnp0yXW9VOmjHrGrNOcRErsbhXa0DWL6tjpmGH5W3z2XTn
> emHaPcVhCLuW9likvQ==
> =pNzQ
> -END PGP SIGNATURE-
>


-- 
Patrick Allaert
---
http://code.google.com/p/peclapm/ - Alternative PHP Monitor

Re: [PHP-DEV] PHP.net is down?

[Gabriel Caruso]

On Thu, 7 Jan 2021 at 13:56, Patrick ALLAERT  wrote:

> Hi,
>
> That is only the homepage.
> The rest of the site works fine.
>
> Could be related to the release of PHP 8.0.1 that happened a few minutes
> ago.
>
> Patrick
>
> Le jeu. 7 janv. 2021 à 17:49, David Rodrigues  a
> écrit :
>
> > Hello!
> >
> > I cannot access php.net anymore. error 500.
> >
> >
> > Atenciosamente,
> > David Rodrigues
> >
>
>
> --
> Patrick Allaert
> ---
> http://code.google.com/p/peclapm/ - Alternative PHP Monitor
>

Was fixed by http://git.php.net/?p=web/php.git;a=commit;h=511182cf, was my
fault after the PHP 8.0.1 release, I forgot a step :(

Re: [PHP-DEV] PHP 8.0.1 Released!

[Gabriel Caruso]

On Thu, 7 Jan 2021 at 13:51, Patrick ALLAERT  wrote:

> Hi,
>
> Since a couple of minutes => 500 internal server error on the homepage of
> php.net.
> Would it be, by any chance, related?
>
> Cheers,
> Patrick
>

Should be fixed by http://git.php.net/?p=web/php.git;a=commit;h=511182cf

My apologies, PHP 8.0.1 was my first patch release process, still need to
fix some stuff in my workflow. Thanks for reporting it!

Re: [PHP-DEV] PHP.net is down?

[Patrick ALLAERT]

Hi,

That is only the homepage.
The rest of the site works fine.

Could be related to the release of PHP 8.0.1 that happened a few minutes
ago.

Patrick

Le jeu. 7 janv. 2021 à 17:49, David Rodrigues  a
écrit :

> Hello!
>
> I cannot access php.net anymore. error 500.
>
>
> Atenciosamente,
> David Rodrigues
>


-- 
Patrick Allaert
---
http://code.google.com/p/peclapm/ - Alternative PHP Monitor

Re: [PHP-DEV] PHP 8.0.1 Released!

[Patrick ALLAERT]

Hi,

Since a couple of minutes => 500 internal server error on the homepage of
php.net.
Would it be, by any chance, related?

Cheers,
Patrick

[PHP-DEV] PHP.net is down?

[David Rodrigues]

Hello!

I cannot access php.net anymore. error 500.


Atenciosamente,
David Rodrigues

[PHP-DEV] PHP 8.0.1 Released!

[Gabriel Caruso]

The PHP development team announces the immediate availability of PHP
8.0.1. This is a security release.

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

For source downloads of PHP 8.0.1 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:

Many thanks to all the contributors and supporters!

Sara Golemon and Gabriel Caruso

Release Manifest here and below:
https://gist.github.com/carusogabriel/277fa09acd2734ec009294990b8d1f6e

php-8.0.1.tar.gz
SHA256 hash: f1fee0429aa2cce6bc5df5d7e65386e266b0aab8a5fad7882d10eb833d2f5376
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl/0cUEWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj5inD/9lbPqTb4709RQIMBGB2PK5HV4C
4oWKaiWy2S0jm9cKwvUqprDJTlKZXglnJC/nJc8oXyekGM5NkuD+lc6FwQvzSA/n
1yXV3aeELy1xG6AvLMTJz8pk9a1peBrpJ6xHtFNI1mPAD93OvE2hoXk6w27UT2eA
i/kM1EI+I6bMUoPwwjk1PTPI7TaIu4FTZbNjxGlU7bcaDMDwgBtQhCPgEq/NbnnC
XW5i4GAMzst7kbsiC3hKs/zew7oh2Yjc7pW5irtplTtL+86CePeu6k6+1Ff0+iA3
61YGjvCLo+PCEzeKyfYfuUZ0Tz3qYGC9/TPx38Tk908EQ32bkeG7/p6uUdg96IWV
l/HN7YcaIA/yo/NMeYvhjKlAFPv3Elo2ZHuhucmAsBQ7CIu3V6Jd43dUpmXAe2PH
Uf4Rxsbvf0TRp2Xja5I+alopLLBceMM6WALVuvdnPhUhgNLoeM3VPijgmkZT1toW
a6pKCg38PwPwSdA6eLeJ9qBz0H8iPUSGS8EuFcB/CbGuw0eJw0yAf990LPttIkca
JJXuhVxBSrSzHL56WvoQ/gxRrf6dK2VfpbS3cjnInXffaI/JykIGiDhfWaIBTxzN
tcyQSEBegTPHtT9PehpxsfO2gKdeQQX+np9a/p0S05tuGsNkjIYFK0lggnwnza+J
oUwxe5oSYVh1DNtMpQ==
=p4/f
-END PGP SIGNATURE-

php-8.0.1.tar.bz2
SHA256 hash: c44e76af40d133de64564f9caf5daec52bbe84c1ccb4e4500a62233d614ebdee
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl/0cUIWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj//eEADEMSfKUUnORTy+RuDBiA/XB9l0
+xk98qG6uyZ2mRv04XjP/qTks1NvY5P6gcjeU5NCUaxMZY4B1grVQECuHnuZx1oR
XZtKRfLpFxN+c5MOQ3zU6We07jWQSJ5827UWPOZlEKvYM7Ta85o2Q6aUwzvHwM9l
E6er6iz2tlLxtgwNYsGfaqMWOSfQP/JjNWHxmSocthtV78g5jum1uc6i87uHOqeO
xZmjpIGCYadXWfd++5xyLzSxlrlV/3sWSFSMNHGytO/R/YgXnpzqnnZK20uFDC7U
3O+C3IPGUr7LUUhJmJz2nCoaO9aLXAQpf4Hf/AzykTksk4u90UIMNf3zHa38b82I
+XWTQ061uUyjL1DVOPFWNtpOLrRJSzk4i5M+VPIOW8+c7FwSdMYI6dHsSqyWIJ+C
eLFwEDrRj9SwuOurNTdML6knoJqvJcGm9Q+IzEwIjFyM1X9cLpnARk/Jeqf1d65C
KMsg6BaDLjQASx3AO+u3uMDs8Qo7zNZjQqbMLk0JjrY/n0ACw5oQM6RdbEsfokRE
kQywZ0bNTOM+jQIAgfCyQSc+PyTUE4TjstZpk+TVdVQ02xdKpqGPDCANv4eP3joy
2qCwLSWZRlbyT+1QH0LpnXR+n5VNetrVPjJsU1rD7/dIOYmWXC7WV59A6mEtzr93
ThdYSpAaIShl7imPxg==
=SnRb
-END PGP SIGNATURE-

php-8.0.1.tar.xz
SHA256 hash: 208b3330af881b44a6a8c6858d569c72db78dab97810332978cc65206b0ec2dc
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl/0cUIWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRjy+jD/914syanckmQVEmVHQs1NQWqv7b
IG4UoN0wdAu44Ks4YC0vRaS3D8BYbZJ4FpZrYRElMupsJqgDhFNAMtv+YIEOMxzc
RuQQAALsBZI5U+5OUP8e12GmprXo8Nm4ppxlAW+/WXOQO/UqWPmlR4KVD+KAAmw/
dnKDx6G+MFKK0i/HvPk8vOkcBXkaJ6mrVpb4oeolSmKBUFuBW2ercQZbotlYv19l
riP5o2Rar71m3qt8HJUBAQgqVAnEjYZQJGy37WceQ6jyHsTpiYmWPlVqZfy0bY4F
uxMkPf+d3bmIJhhHwyi3Z/SJMq7y3XbQiLAAgjBHhKuDX/LJxO6EAvDceGX0Ptdz
i9j1Z6i30SDAdQC43jv7uYTuonwySzM9bUKh0py2lOe5GAMORVTQ9oez4OD7tN6R
zkGL0IgbCtWkpdB6zayT2aHl5B0voz2a4OPy5P1Z+RynnWndvDAID+IPMeqTDIVY
KPdwYUwCPJAliR/f7MBfJUkVZ4IYvAO6sIOg23yGQyE039l18jtDHYQ0r2D/KIc5
/6h7Eo9uc+JoAJayvdTUB+xxVZx1dwusUo4Icm2UWXtVynyX8Rt8Oavn/V4Ox1bo
5r25DW2tOrjKoM80FcPnp0yXW9VOmjHrGrNOcRErsbhXa0DWL6tjpmGH5W3z2XTn
emHaPcVhCLuW9likvQ==
=pNzQ
-END PGP SIGNATURE-

Re: [PHP-DEV] ENT_COMPAT for htmlentities and htmlspecialchars

[Craig Francis]

On Thu, 7 Jan 2021 at 14:11, Claude Pache  wrote:

> Hi,
>
> > Le 26 déc. 2020 à 12:02, Craig Francis  a
> écrit :
> >
> > (...)
> > PHP uses the numeric version ' with ENT_QUOTES, and it should
> continue
> > to do so - because the named version, ' was added in HTML5, but can
> > still cause problems with legacy parsers; for example Android 4, and the
> > one still in use by Microsoft Outlook (&/>/< was in the
> > original HTML spec, and " was added in HTML2).
> >
> > (...)
>
> I agree that — in addition to ENT_QUOTES — ENT_HTML401 (which encodes
> quotes as ') is a better default when encoding, but I also think that
> ENT_HTML5 (which recognises both ' and ') is a better default
> when decoding.
>



That's a good point for decoding, if I saw:

echo html_entity_decode(' ' ' ')

I would expect it to decode both.

I'm tempted to update my PR to use ENT_HTML5 on `html_entity_decode` and
`htmlspecialchars_decode`, to avoid that issue.

But the tests show that it affects a few others, which I think are fine,
but should check what others think:

  > DECODED, Form Feed
  
> NOT DECODED, Carriage Return
> NOT DECODED, Invalid character
> NOT DECODED, Invalid character
> NOT DECODED, Invalid character
> NOT DECODED, Invalid character
   > NOT DECODED, Not a character
   > NOT DECODED, Not a character

Craig

Re: [PHP-DEV] ENT_COMPAT for htmlentities and htmlspecialchars

[Craig Francis]

On Sat, Dec 26, 2020 at 12:03 PM Craig Francis  wrote:
> Could htmlspecialchars() use ENT_QUOTES by default?
> [...]
> I'd also be tempted to suggest ENT_SUBSTITUTE should be included, as I prefer 
> to keep as much of the valid data (rather than losing everything), but that's 
> not as important as escaping the apostrophe by default.


On Thu, 7 Jan 2021 at 09:00, Claude Pache  wrote:
> For ENT_SUBSTITUTE, there has been https://bugs.php.net/bug.php?id=69450, but 
> I don’t understand the objection in that bug report. Maybe there is some 
> issue related to non-Unicode multibyte encodings?



On Thu, 7 Jan 2021 at 09:29, Tomas Kuliavas  wrote:
> Only ISO-2022 encodings got bytes that can match symbols sanitized by 
> htmlspecialchars.
> 
> Bug objection insist that utf-8 parsing rules should be enacted by sanitizing 
> function and not by application which displays text. And PHP code is enacting 
> those rules in most unfriendly API way.



Does anyone have an example where ENT_SUBSTITUTE could be used to create an 
issue? ideally a security issue, but anything will do.




With `htmlspecialchars($user_value)`, I don't think it would matter if it ended 
with , like the example from Rasmus (0xE0), because that 
end byte would be replaced by U+FFFD.

With `htmlspecialchars($user_value . $system_value)`, if $user_value ends with 
, it's possible some characters at the beginning of 
$system_value could be replaced. But I can't find a way to do that with UTF-8; 
and even if it was possible, I would have thought some characters being 
replaced by U+FFFD, would be a much better solution than everything being lost 
(noting that $system_value will not contain any HTML characters, because they 
are escaped as well).

echo '' . htmlspecialchars($user . ' is lying to you') . '';

With: 'ABC�s lying to you'
Without: ''

And, in both cases, the output is valid UTF-8, and shouldn't affect anything 
it's concatenated with (i.e. the HTML context).

Personally, I think every part of our processes (input, processing, and output) 
should do its best to handle encoding issues (incase something is missed). I 
believe ENT_SUBSTITUTE is the best way to deal with it during output. I don't 
think it's realistic to expect every single PHP developer to check for invalid 
characters in every single bit of input.

That said (and just to make things even more complicated), considering this is 
HTML encoding, we could go even further and add ENT_DISALLOWED. As Hans noted, 
some characters, such as 0x01, can be seen as valid in general, but not valid 
for HTML (where Text Nodes "must not contain control characters other than 
space characters"). All browsers seem to handle these control characters (by 
ignoring them), so I'm not too worried, but if it makes things safer, why not?

Craig

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] PHP 7.4.14 Released!

[Derick Rethans]

The PHP development team announces the immediate availability of PHP
7.4.14. This is a security bug fix release.

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

For source downloads of PHP 7.4.14 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.

A migration guide is available in the PHP Manual. Please consult it for the
detailed list of new features and backward incompatible changes.

Release Announcement: 
Downloads:
Windows downloads:
Changelog:
Migration guide:  

Many thanks to all the contributors and supporters!

Derick Rethans

P.S. Below is the verification information for the downloads, which is
also available on
.


php-7.4.14.tar.gz
SHA256 hash: d359183e2436f4ab30b70d4fbd881b5705a46b2e68cc6069fe91cd63d6e98e13
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl/0Q7sACgkQkQ3rRvU+
oxIyThAAh/Dr2aDsb7v/keyTKJACOBoIRJ1qSbR/dOJtxkRUtjHti6QNgM9/kUpI
4o05eu7rLwZLrlcojG9jTXdMoLPLaVRjy3gFCTkINU5pRHK7lMgsmQ3fW0ZRaams
+a+cfnvqCn1Z5sCrw21ujtwOF9cSTIlP1RtcUmo5MjELyVjI7YgrvUGcenR8Wztf
pgK9OdUvC7pdHwvcCaOawXvyjCxl1nK4Ugqmz4oN5tTAMidt+rsHgo+xCk3SOwrs
mOAF4eBPlFVhRhz1L4QQIrjEGuxoIF9PJJpVXdMXwFWeVdVaRcG868BWFi1kN0HJ
0hiYuFuARBkdbNpAMv3n2yrwV9rBfqeMBQkYGNFZorFOpaFZZNfMYV0wNE5YyAZK
/3E2Jo1eK65ahNBE9iXfYnP9DPqzcSgM4eP0fiXBntvR7EwyQEZ49EjOfkSqZqPu
9uLGKIXYuu3sTqaap4/6Ns+yB0XEaPfBZj6xa0R0x0zw2qFXmsWHUYb0buIOT8yY
mCX4x7jc+Ay5bt9hJFrbYbOSDZApxN4kNKzB9pR2xrgyZ2VmjN81pZAsKzdrO2Kw
pJzVSuN/H4zhVDKrO6S57WQqRe6KgGZhiepCm2OBgYbbZ+MC0JHaYKM6eZsHGhif
coPSICPXELkH6lySGVKkqPn+iL0ja6dwfsT8JD9iPxUXWEgk7zk=
=wG5a
-END PGP SIGNATURE-

php-7.4.14.tar.bz2
SHA256 hash: 6889ca0605adee3aa7077508cd79fcef1dbd88461cdf25e7c1a86997b8d0a1f6
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl/0Q78ACgkQkQ3rRvU+
oxJD6xAAsmgH1sKwgkiqB7EQfpa2O4qT/pP0rZj2YuRfcYBGCq/+Hyofd69Ev8Mr
+Bhjppcvi+Yx2ur0h3a0g3AU3uI1QAqc1Vkh0IZOHAOCVFlfXA2M7cvp+XBTDFOC
zYTqAuOF18w8BG0EKtOhg4DluQsRNT9v3NY2MttvD0F47reppoIwBP7SilTvJtfO
c0xGfQ778LcancWWp/5d1gT2HKMwpGHgKXdFhcYwjP16TEl8ywSIyMJbGGimrUQn
y+zV+LrC2Lb1UYj9Kzjru4XyDPa0ANfbEqtOh//2ROGp87c/LbGD/r+U08rIHr0O
IZVZ1iRq3F1gFfeKMirNL3d/j+pE8sT7FyikyA+wM7UiQCYptUg50kiowufheMDH
4k0kIbCP4m7KQ/MUzAhayN5Q5NHEc815hTvb3/0OGTSgLP/Z6d1NJbVSbpdzBeQE
HdilE/uuKnQ2DQqzSoxxlMZeX5uVG+ZzA91Uvo42BJ4w4buO2X9BbLah3AMrHZoP
Lt/0AuJUK/yNSKEd9079WPyBBFWHIcuHa1/mxvX8FX8sYCSc+XtBSw1GefxVtZZb
Z7Q6bd6IZXynOwsI9gIPrMAt18JI5NNafUAeW4u4idZa10FDZJolxHFomPJuVZCu
s3lpEUjYLNad3uFT4HL+E0nwjSeTY46ADkTtZDbzzcA2zsAIVDY=
=UVVD
-END PGP SIGNATURE-

php-7.4.14.tar.xz
SHA256 hash: f9f3c37969fcd9006c1dbb1dd76ab53f28c698a1646fa2dde8547c3f45e02886
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl/0Q78ACgkQkQ3rRvU+
oxKR2BAAq2058Q3ZKFKt3H2tB77Q+TZLUMIYdgtem3gZyfh2/UwzKxwUus3/iN68
ad2txzdP9SimmW2eXkvc+PAOKgacTXenc7pioJVIfnXvE7GHrLQVq/dHBOZ+S3cH
0gOgA9Mu2ZGcPRYeDRIba+JR3t6QnblqxrKAMnCq7nCtYQt+S8ADD/exkLGOm7li
1qf2uLqIpi6cp7SYGJZYWEwoxBso5OUZ1jbCb7O2llxgEqeYIBd+4fY0RVLjtnzx
6sJLFp44pkh3WERaeZr8NAdqa2JGCvX1cj43R+TP8X9VF97RM+34EmhsFcp88wMq
Xcm/GMZWx8LVLyqNNPWKJ4BvzxNY0+lop9M4URASZR0Vowx3shLVOSUfwx6251Xg
riyPdWxkhSl2aqwn+IKfIKEVzinkvH+dzy/ujeVgA24aZkmyAk19Zs7R8jdBKl0F
fsw69PNoXlALobVV1gyr0Mi5/Q24rFialzm5uOFtDHmGt4DNSIVw9Z2x0qny8732
rnTY4Vo1CtQobNLtoneoiGh5t3+TJDNY3Ip7CD2mJ+B/IULlTv9h4thQKJvvANea
SuqlKpq94hy68mYN0Jl1mBYcRRL5V40Tu+iDP1mSYjEFajEEcRuCl3fClMvERzHa
cAloXVJg72C4WaYUNi6FKsJFwIt1eqvBE28Sb3YYcyDTGeAZoPw=
=IrGd
-END PGP SIGNATURE-


-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] ENT_COMPAT for htmlentities and htmlspecialchars

[Claude Pache]

Hi,

> Le 26 déc. 2020 à 12:02, Craig Francis  a écrit :
> 
> (...)
> PHP uses the numeric version ' with ENT_QUOTES, and it should continue
> to do so - because the named version, ' was added in HTML5, but can
> still cause problems with legacy parsers; for example Android 4, and the
> one still in use by Microsoft Outlook (&/>/< was in the
> original HTML spec, and " was added in HTML2).
> 
> (...)

I agree that — in addition to ENT_QUOTES — ENT_HTML401 (which encodes quotes as 
') is a better default when encoding, but I also think that ENT_HTML5 
(which recognises both ' and ') is a better default when decoding. 
This is not just when $flags is missing, it is also when neither of 
ENT_HTML401, ENT_HTML5 or ENT_XML1 appears explicitly in the bitmask, i.e.:

htmlspecialchars($x, ENT_QUOTES); // should be equivalent to ENT_QUOTES | 
ENT_HTML401

html_entity_decode($x, ENT_QUOTES); // should be equivalent to ENT_QUOTES | 
ENT_HTML5

The difference between ENT_HTML401 and ENT_HTML5 and their practical effect 
(one of them more compatible when encoding and the other more compatible when 
decoding) is probably too subtle for most people, assuming they even know the 
existence of such flags. (In the codebase I’m taking care of, there is 
somewhere a comment that says “html_entity_decode does not decode '” 
followed by code handling manually that specific entity.)

—Claude

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate passing null to non-nullable arguments of internal functions

[Nikita Popov]

On Wed, Dec 16, 2020 at 10:50 PM Craig Duncan  wrote:

> While making internal functions treat non-nullable types consistently with
> userland is an absolute win,
> I do wonder if it should be done simultaneously with changing some
> functions
> to formally accept nulls.
>

PHP 8 made quite a few function/method arguments nullable to fix various
behavior consistency issues. That said...

I'm thinking back to all the pain caused when *count() *starting raising a
> warning for null values.
> We saw a lot of code that passed undeclared variables to *count()*
> and I can imagine people writing similar code with something like
> *strlen()*
>

I don't think that making the argument of strlen() nullable is in any way
appropriate. This is a case where people will just have to fix their code.
I do think we can relax certain type requirements on a case by case basis
(e.g. the fact that ini_set requires a string rather than any scalar value
seems unnecessarily pedantic), this just isn't one of those cases.
Generally making arguments nullable mostly applies to arguments that are
optional.

Regards,
Nikita

[PHP-DEV] PHP 7.3.26 Released!

[Christoph M. Becker]

The PHP development team announces the immediate availability of PHP
7.3.26.  This is a security release.

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

For source downloads of PHP 7.3.26 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:

Many thanks to all the contributors and supporters!


Stanislav Malyshev, Christoph M. Becker


php-7.3.26.tar.bz2
SHA256 hash:
371e5a7c8154fd3c52b14baace5f7d04c4bbb8e841d356c54a2b6a688db39d4e
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl/0QwYMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2Vq4P/A7DmSu1nIpczOTQpPb92En4axezwa34USf8xeC3
6lUrADZINqBqlSRg2ZpH4p/w1Mz2prws0K34k3LIEUk/6HN9M7PMnS0Ltzc9JGki
I62jjmoWuvIBilaHTV6GRuXH6n4Z9HvB1Tll69e5kTmrWecrBfTPg4BwUhI/T3MA
RXtQr/C/6yaZeL6N7h0K8R8RZ1xn3DqeZDaSRdhHlaoJixqZWqOd2nCVhmuw3EPI
igtPIi3D8+VGOkPcBR4luW3WZSW5zs+KzJpmy4DPPLDRe5iOF4VP8PsI3uFyML0O
7ypCUigpIOWP6aRpB7yQW4/YoHdJ7h8elV3l+zm83Lp8/LQPu58C/1ogeVmw97H3
YMpxcEYWfSUX4lV2tiCeZpIDdRzuvmxpiiVtX8aY0JKgyJo5clX+dv5eulGIWkd0
JoVrT0OI0WNl38BVinr1sDNJyFYgIqMswm1PgOslMbQpQvjSXRNWnRYvDSmrzKpt
ZvFyR6VPbdNjRc6cP5uC0DEe2Iou537lKlbmYirJKxOjSTKULW228Z+AgelxRHdV
KQec70isdqly0cvr3ZgYFgG1hl04pYtL9SOwf+xzjsEJu4HFSkivRy6DCeahSYlw
+WT+I8YIzW+iEJ6jbIghMHsvB1uDCplhCdV5G26RLZV4PlxdDzsfc0+/hQfCIPUS
k4E9
=aXl6
-END PGP SIGNATURE-


php-7.3.26.tar.gz
SHA256 hash:
2b55c2a54d1825e7c3feaf44cf42cdf782b8d5c611314172fbf8e234960b6a99
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl/0QxEMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2z4MP/jWTmYiQ0vrEAC2CGyzZCX22t4xuJPlCGQ85En8Z
Z0m+kUqrcgBiDGQ/ko0HhzSqzp94qaRBL/lLrJIhPVfLV8bjpv5jhe0Zcwc642WX
fjV4ylSUs1DsxUSC/6srUQqqtwvHe54bt3xU9eglSjfBarViUytJ7Y0YqA//rjQo
dy8mwLRf+9hWYQ45a1vJboVgUuSoWTA7YdZ6ImWxAzArpCkUDkBhDE0udcGqmlRz
ykbFFhKW2X5ydrcsW9HOtVVoc5RjTmMZEkRdmRsY9ZEWtazInLkxTsDDGNG4ji7P
F/bxX7CwXl2AVY9dhtGDFO4iTRmg9rQQGa/kPF5wwclZvctegUk0oTkddOPwh1e7
tSMW4BYoNGoPxuejasIrlfrHyckJOTjINhINpcG8GzX8plonZy2vctdGs+h/DKgy
Z5aHHOmVUCDtPi2UnzaRgAmAc0fHdeyCReGBWYjEbA3IfVMkC2nreg4e5aZZc6cY
xiB8zPJ6PvXAMOZo+5bnfwcz34efNKG6s1HmelMMxZjjV4lO9OrlRY2DC20+44mK
KwGLJLHA09AkkLlCfsJ8h0uLqRQSH+USxvMi6m2sNRsN7XcPbSJTepYsxt/NqqUD
RH47Hq8EcLRJ5gv1knKpcwq/msyNpEMDQkA8Kv1nGEwoDAyxp9In0y/079O+q5R6
JM9H
=XWAg
-END PGP SIGNATURE-


php-7.3.26.tar.xz
SHA256 hash:
d93052f4cb2882090b6a37fd1e0c764be1605a2461152b7f6b8f04fa48875208
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl/0QxEMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y21vUP/3YYSI+MzOemyIWpeQyly9Kw3OUoqwPPdgSo/fy+
Ok9hf/AQR64bULpRlVxoNKFL3TtlnJ0hKSEH6sAGujg9eLyW8ETbVlDh5PvNCkOn
7cKGuD0WrmjlWaMg2CGX3EYDa2mHZrznCqPjyJL26SByCTkD4s2BuYuRIM99Jhhb
mMjb1cfdh3LRZ/eG0WXEMTg2zvvvTA6PEl3fHwusMjkr0C9OfF610wJNhWOcZ6JP
B69crTnR0O8yP9CSvD/ULP02P2kQ2znNZySqVXTfhpnhv+IpvXzTkVZIhVoqqyxY
QOVj29q1ChdfoAf1tOyVFG5JGKyxMnLpIF7E3puVBzuVaPl+ReXnfd/rHNVEsWXz
hXcsHY6Ll41tkVbXbiBC+RKyf3r2SlnM8A36mLMX6dW/CW3sEwofvh6b2X3go/Im
lavdIR+n/PobAu9oM9iVfbT9TTFSMCHzdJgk0Gxz81u4eXcH5pQ8dcyD0bgJdEQ5
j+ThSDaPSKKgjE9Uuttp8rWP0EikP3lMdBtnJAv9p8rMY8vG9jYgbRlNVhZEHkH6
4SX6WmGgHjmSf/UymX4AeswkFU+OmMiKPre821hjS4Af5lXugms3hAO9t9dPctFN
PlQuK2cA009ZXoCC9TouCbBaWwL7zYI9vGvBZFUl8BB9Z8SVzySQVm3AWXfIHGli
KiJy
=/hNi
-END PGP SIGNATURE-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] [RFC] Array unpacking with string keys

[Nikita Popov]

Hi internals,

I'd like to propose that string keys be allowed when unpacking into arrays:
https://wiki.php.net/rfc/array_unpacking_string_keys

Especially as unpacking in calls supports string keys now, I believe it is
time to drop this limitation for arrays as well.

Regards,
Nikita

Re: [PHP-DEV] ENT_COMPAT for htmlentities and htmlspecialchars

[Tomas Kuliavas]

On 2021-01-07 11:00, Claude Pache wrote:



Le 6 janv. 2021 à 16:46, Nikita Popov  a écrit :

On Sat, Dec 26, 2020 at 12:03 PM Craig Francis 
wrote:


Hi,

Could htmlspecialchars() use ENT_QUOTES by default?

I recently worked on an example script, where I tried to keep it simple by
using htmlspecialchars directly, e.g.

echo "";

I'd completely forgotten that single quotes are not escaped by default,
creating a XSS vulnerability, e.g.

$url = "/' onerror='alert(1)";

All the common frameworks I could find use ENT_QUOTES to do this safely
(details below).

Christoph (cmb69) suggests this was done for HTML4 compatibility, with
older versions of PHP possibly having issues with numeric character
references (a quick search suggests PHP 5.4?).

PHP uses the numeric version ' with ENT_QUOTES, and it should continue
to do so - because the named version, ' was added in HTML5, but can
still cause problems with legacy parsers; for example Android 4, and the
one still in use by Microsoft Outlook (&/>/< was in the
original HTML spec, and " was added in HTML2).

I'd also be tempted to suggest ENT_SUBSTITUTE should be included, as I
prefer to keep as much of the valid data (rather than losing everything),
but that's not as important as escaping the apostrophe by default.

Craig




WordPress uses ENT_QUOTES (ish).

https://developer.wordpress.org/reference/functions/esc_html/

Laravel, with Blade, uses ENT_QUOTES:

https://github.com/illuminate/support/blob/master/helpers.php#L118

Symfony or Slim, with Twig, uses ENT_QUOTES | ENT_SUBSTITUTE:


https://github.com/twigphp/Twig/blob/3.x/src/Extension/EscaperExtension.php#L243

CodeIgniter uses ENT_QUOTES | ENT_SUBSTITUTE:


https://github.com/codeigniter4/CodeIgniter4/blob/develop/system/ThirdParty/Escaper/Escaper.php#L120

CakePHP uses ENT_QUOTES | ENT_SUBSTITUTE:

https://github.com/cakephp/cakephp/blob/master/src/Core/functions.php#L67

YII uses ENT_QUOTES | ENT_SUBSTITUTE:


https://github.com/yiisoft/yii2/blob/master/framework/helpers/BaseHtml.php#L111

Phalcon uses ENT_QUOTES:

https://github.com/phalcon/phalcon/blob/v5.0.x/src/Html/Escaper.php#L78

FuelPHP uses ENT_QUOTES:

https://github.com/fuel/core/blob/1.9/develop/config/config.php#L459


I agree that we should switch the default to ENT_QUOTES. I also agree that
we should enable ENT_SUBSTITUTE by default. I don't see any downside to
these two options.

Would you like to submit a PR?

Nikita


For ENT_SUBSTITUTE, there has been https://bugs.php.net/bug.php?id=69450 
, but I don’t understand the objection 
in that bug report. Maybe there is some issue related to non-Unicode multibyte 
encodings?

—Claude


Only ISO-2022 encodings got bytes that can match symbols sanitized by 
htmlspecialchars.



Bug objection insist that utf-8 parsing rules should be enacted by 
sanitizing function and not by application which displays text. And PHP 
code is enacting those rules in most unfriendly API way.


--

Tomas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] ENT_COMPAT for htmlentities and htmlspecialchars

[Claude Pache]

> Le 6 janv. 2021 à 16:46, Nikita Popov  a écrit :
> 
> On Sat, Dec 26, 2020 at 12:03 PM Craig Francis 
> wrote:
> 
>> Hi,
>> 
>> Could htmlspecialchars() use ENT_QUOTES by default?
>> 
>> I recently worked on an example script, where I tried to keep it simple by
>> using htmlspecialchars directly, e.g.
>> 
>>echo "";
>> 
>> I'd completely forgotten that single quotes are not escaped by default,
>> creating a XSS vulnerability, e.g.
>> 
>>$url = "/' onerror='alert(1)";
>> 
>> All the common frameworks I could find use ENT_QUOTES to do this safely
>> (details below).
>> 
>> Christoph (cmb69) suggests this was done for HTML4 compatibility, with
>> older versions of PHP possibly having issues with numeric character
>> references (a quick search suggests PHP 5.4?).
>> 
>> PHP uses the numeric version ' with ENT_QUOTES, and it should continue
>> to do so - because the named version, ' was added in HTML5, but can
>> still cause problems with legacy parsers; for example Android 4, and the
>> one still in use by Microsoft Outlook (&/>/< was in the
>> original HTML spec, and " was added in HTML2).
>> 
>> I'd also be tempted to suggest ENT_SUBSTITUTE should be included, as I
>> prefer to keep as much of the valid data (rather than losing everything),
>> but that's not as important as escaping the apostrophe by default.
>> 
>> Craig
>> 
>> 
>> 
>> 
>> WordPress uses ENT_QUOTES (ish).
>> 
>> https://developer.wordpress.org/reference/functions/esc_html/
>> 
>> Laravel, with Blade, uses ENT_QUOTES:
>> 
>> https://github.com/illuminate/support/blob/master/helpers.php#L118
>> 
>> Symfony or Slim, with Twig, uses ENT_QUOTES | ENT_SUBSTITUTE:
>> 
>> 
>> https://github.com/twigphp/Twig/blob/3.x/src/Extension/EscaperExtension.php#L243
>> 
>> CodeIgniter uses ENT_QUOTES | ENT_SUBSTITUTE:
>> 
>> 
>> https://github.com/codeigniter4/CodeIgniter4/blob/develop/system/ThirdParty/Escaper/Escaper.php#L120
>> 
>> CakePHP uses ENT_QUOTES | ENT_SUBSTITUTE:
>> 
>> https://github.com/cakephp/cakephp/blob/master/src/Core/functions.php#L67
>> 
>> YII uses ENT_QUOTES | ENT_SUBSTITUTE:
>> 
>> 
>> https://github.com/yiisoft/yii2/blob/master/framework/helpers/BaseHtml.php#L111
>> 
>> Phalcon uses ENT_QUOTES:
>> 
>> https://github.com/phalcon/phalcon/blob/v5.0.x/src/Html/Escaper.php#L78
>> 
>> FuelPHP uses ENT_QUOTES:
>> 
>> https://github.com/fuel/core/blob/1.9/develop/config/config.php#L459
> 
> 
> I agree that we should switch the default to ENT_QUOTES. I also agree that
> we should enable ENT_SUBSTITUTE by default. I don't see any downside to
> these two options.
> 
> Would you like to submit a PR?
> 
> Nikita


For ENT_SUBSTITUTE, there has been https://bugs.php.net/bug.php?id=69450 
, but I don’t understand the objection 
in that bug report. Maybe there is some issue related to non-Unicode multibyte 
encodings?

—Claude