[PHP-DEV] PHP 8.2.20RC1 available for testing

[Pierrick Charron]

PHP 8.2.20RC1 has just been released and can be downloaded from:

https://downloads.php.net/~pierrick/

or

https://qa.php.net/

or use the git tag: php-8.2.20RC1

Windows binaries are available at: https://windows.php.net/qa/#php-8.2

Please test it carefully, and report any bugs to
https://github.com/php/php-src/issues

PHP 8.2.20 should be expected in 2 weeks, i.e. on June 6th, 2024.

Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/bbfefee22776e04505286d9ba6d27c0d

Thank you, and happy testing!

Regards,
Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.20RC1.tar.bz2
SHA256 hash:
7b899e4175e8a3948182b2ef1ac0af960d81e011b3c9c363c002c18202157f52
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmZM6YwRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwBpxAAiMESLH5k1/z8EmbzpnDtGSZwcxQhENPu
7EOUh90A15rOCymJeXSxe3qhYmtYy0r7AaidnDZ7fDQqhtPoWmrU+1mDwhoQoPmM
iQ3fsKD1DGYN2cfmq6c/VFiB5ZDvIsxS9anGuJudOetCtQyclSS4FVyMkHju2i7j
a4TYAzRUnddIfH3W9yx1Z0VdbsUtn7657V0j7lY2RHYt6KBD7MAq2SyRUgASbmBV
80dijLty6f5snXMK+MKWbW38cNkiEk3VzkImG9tHBpraySvC16nz+otKVKTp4Beq
z4yFEG4sXfxQryTIDKx+SZJJuhnWflbmfZ7mEtNb/rRueTQ0vEYabWiRYYQR+yz8
za0bnTpD14T6JPW8jaXC5Lm2Rxp8ABDQE8XcOwfI9UBkGdukC3cZHB5U8//LLtCW
m+gq8X4xYBnsfENlTYfagkv2RSzjXJr0zTMYH4rzW31ZfrlTqptnpvjE5XP6UVRD
QQd3mZrZxjyaRWue7kwoCzR11WtTwbCYGZRJvyiAudlWtw2EFMyAHDZ7Sc56AD9k
5CZoi6E6EQh5ol7wX1il2MxDDS6gfRHLrY+1saMXy+5TITcn0wJanPSo0kQ0cWs9
ho+6tAg8TclWRKvTMUFGxLMua57Inb6oUMIvwpe6ECwni/huInvbdTeKRQ0FzNOB
bTR4Ilj041A=
=wAxK
-END PGP SIGNATURE-


php-8.2.20RC1.tar.gz
SHA256 hash:
f1cf16df37e5f193f327af3ca4c6f13111cfbbfd931f5c2f41bf7f2514083765
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmZM6Y0RHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzfhA//VN1TCGF5WycCTKLVKbHxIn3AGxoke9WT
UA4JXSDOKBwG15mDcbeuUF0FyDuDb4NjXVde6kJlISBndkVnJcihRQLZ2EUb1nsV
7us/DAw9cEwFVGCAp+TgQcbqx7kJrlUHxI3Eyg+dqv8n/Fhm+5VXIn3hCLbW3GJV
9Yc2HXByPdqFRiR5Awq1iQDMsewDI7Wy3o4ayxwMdHOZjRDBw5qIG1ZKYND9q3sD
KRXZaXF13WMdQh4TU5Sgw/nKWWTqRnnzMYGhp4awEX9J+2YjGIn08YR/kyvrLTLm
cxwhZWIniz5IapFXAgjyTaBpQkaMirS1Y0VJnmavQABoyv9e0wR/FwzMC70uDZFP
rgcbXiApR2+oKwOnCUKFV8rvb8WO5djQoWD5XHBD3McYSnk000vgrMvCNalNyENP
TebFIumSLAE+1DpaQBPU04jIagOfTiF0IUUCVSX9ZIw4VcQrq7A/AEf7WwEkU13I
KL+QY81TkVmHdDWtHZoYpNTYkk01TMGaR2cjbhINIkp1IhaqUxkMWT2uJ5iRjF2i
5RBGpWfZwyMajtJMFxyvqz02SebS9zUZoJ4TBtuP7VijCHjvWzrDbqAEelgUaIN+
tDVN7Rpc4hlhcIMKlzxH/Nr02Gm3jzkWYVV8Jwso0ztL1rO/XvpVQbtlEJ/raOkF
SIiiDE/sKjk=
=1TyK
-END PGP SIGNATURE-


php-8.2.20RC1.tar.xz
SHA256 hash:
6eda8b5e80504907bef2c6471c51ac1ddb00518a799a6363a5a80a1b9e1af147
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmZM6Y0RHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0ady9Xw/6AoPQ/ByquY/id3vRfq0x3Je7Nd+ZgDRr
z/QQMvcBM3FYkXI5G1vx1Hb4EvmxXKookWmOceODxmmmi1kEr4Q1lDlLzljNZH8X
jAv45vyo20JtV3HbHAXPlGqs41iBIP37c73n2fiPJUiTQstyqyPJEGRjCxivrtkF
QqLWAiGrobSY/lC8EzMrMLCoM+uv/wPRaz0V/zTLzNK4gyTSYSi7nmUdiICKA/zk
m3LfPxz6LREPbNqHXnZ1W+SZet+esO6YQKYYhcgohhWVpSeyTtAFCme8ZQwCSa96
oJcVguMiMzZTxYXQsDfDjuwAaRwQBRkVkXYsjKKD3Luc38YimZELM09c+JfeF3Uf
MyoQHEvPQBF3gbvLwvzgTgZAgCkcH438EPK0Opb1U6KvMShaOEclOV7YGJWuXqdx
irC5FDPzN67bEnts66tVveO1wsIEOSzdJr+iReIBErBHkHkXqLpmruOBGEwMkrcL
mt6UNAGubx2d6V5gaWWVb8XZ1piHMARuo1L4pcF0BSAi7OXL2KPWmAdByUcmY/wz
Wh1JP8wSgxwDqTU09DrN6WyLr+5CJB3T4+/yH3G7M2JYIsgLPyLO7PC4xNKbpSGM
+a5aZVP2CQKwa4hZwSXY/MalKGuC1V3nWCrqTmiu/KcauFh2fzvNB1ns1m+iPbES
KZuodtolqP0=
=wPDG
-END PGP SIGNATURE-

[PHP-DEV] PHP 8.2.18 Released!

[Pierrick Charron]

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

All PHP 8.2 users are advised to upgrade to this version.

For source downloads of PHP 8.2.18 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_18.php>
Downloads:<https://php.net/downloads>
Windows downloads:<https://windows.php.net/download#php-8.2>
Changelog:<https://php.net/ChangeLog-8.php#8.2.18>
Release Manifest:
<https://gist.github.com/adoy/3d3a965ce597435758024dce156a8447>

Many thanks to all the contributors and supporters!

Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.18.tar.bz2
SHA256 hash:
ca0b07c254200320f518ac5b3df540a9cf14d866f3c93edc3013b52e06fac796
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmYVjVoRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adxkvQ/+PlNTHY2iM3IVZIYvp6bKTCs0RYikHyep
sFMtFBunEPzP2FYWV63Q1W0iBqBleA6rSplVkWmEH3HxZZ5Dpq6MgwZOs6w3ynZz
vPX92DgRsXpfP2CxFwso9yWGFKmhyWD0UBdNZcEEWmFcNMOXXP5yuF41kVvqnJ+R
9nTdGtHN+SSoWeqfb1MGsrWoiPoo7BtfEW/PBWGehrrYKApHlMzDX6MKPMiTJBEW
KQYh4KJdBac9eJCC7tXmvR89xq1954+78ofvdjm1B09BEiqTVdqqgu0KzHW76vlD
VNqzbJQ4VZneqTNSHO6oEWk4M60CUHbDZ27wGvdkrpS+2ucR2fX5YLb1TTheLEay
/GSrjoiQWTXZIRNgaCFDuW1uZIwzw0cFxlO4z+PH6HcnyBNhldzaNVJtOw5E8BEt
hzKBWmw1K8RoK47m+oFov82eool/Z5o0Zawpf84B9Cv/ERFo0QAwdzwpcM6JlTgG
fjoSWzql+F5gWmcEpgrcBsCXICxDUgjRDBiD7D9BEs2QwytS/5CVZQE23AOocZlL
T4T5EM/Ie3hClWVAH/toR0gCS0faQrLAAx6BgpNO3qpBEg9iP9hnYdbBKMgFAxRg
4Z9zMFalD+sNpvksRhofIpPK1epaT+vRwx+fxQ2gXcJm8lEc47VhCN5SQd8Ex7SI
tCXy8u63g60=
=5Pl+
-END PGP SIGNATURE-


php-8.2.18.tar.gz
SHA256 hash:
b934ca7e8c82945c5cbf0aa2a3f66727eb5b5098e551819e1b090572d6a51ead
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmYVjV8RHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adyQrQ//So3dKNN9W4+POpfimldUTY5/QUtKnWiv
T4iID7mn+bt91T/wQkVfsDeY5dmb3W3HQ5dtB5xji7BbGOAC5duSZiAarWmOJHRm
m9I2RbXrvLzEZuPOJCNLBXG0FqVpr8QBKioBF0FsqnSKNu0sHGMiCpsYPkTFNuxN
/GmBxskS9oINycvTfGUM9uWvFMkbWIYdwkrCn/tQjcPW833iFGdpSX0/KLEIDTUe
bDNgD5mVgt+Gdmu1VTN3sZYAv2t3BVdgakV9wI30jv8dkwFeybVSH+L3MRsW2YMA
fry+IzPPlBR2WgptFNEnp3HXe1U+gc+IRhSHVp/EzXbt4bSP99wh+nosq1jmqSHF
REDIr9LHe/DPqoH2VNZ0KA1a3G5a5V6p+88cvYIVTCAUMCe05hfT7wB6IEn4t3zT
B6hx28zaPn1KIuckKv6kf8GfsWzSMvJQMOZaJb8cUH380F1Q53/vPMJP5+7QQYeH
GaQRfLyP+mPKNAcQ9TK3K2WNCGSR9vAF+2sjR/+b2I2YuzghGDT5Eq8Qb1fYuMDo
+KhKLcY0LBwAbPPXHyg96MI5b1QLRAiaA8+if17hl135PecOO4bL7XdLq4mZtT1O
IbI/37z/jmdoIz4nwqyXIxR0ik3kDy46PUxhfYIg+b3o+hXmDIl8202wxnwixazu
kWsQaqvLi7w=
=+dSs
-END PGP SIGNATURE-


php-8.2.18.tar.xz
SHA256 hash:
44b306fc021e56441f691da6c3108788bd9e450f293b3bc70fcd64b08dd41a50
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmYVjWARHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzsFA//egQ1i7V64nxgDF9IqUwRZ/1T6S+zqGlX
wczmmLuI+CVHsXD3jFlLmh/CLwtxjB8iv3+aj1nXhn6G3ZyWEI2o/qlM4m1z5+q2
d/WQfgz98HmswQC1WUJXsvn+j8pGMW1kM3S79rIft5nCFPnjhuZ/HHfD3si1k7Et
yMH7arZZeuQrSCGzWoqbPLErqCfVbSceV+WDoNzv0HRiK6g9s5wxKoj2+RZTvXIV
u3dx3LEYbPDtJ2yqZjNDlZ9AxSfFVER1T7gby+1TvwbGFxGqvo8OERBwcBioTIZJ
MW+VwC7lAbbRKqlG82SiWxZvxo/25lTlSP0rJTH5cNJaiLirDMF1h59Nn+LsiGo/
p665V5YDMwazxe2KdKCF6rxo5aR7hlNvhD+2g28qITrjBE8lRQ5daPnCIzHpRXW7
TQRzYrqo4qJpnp6F4CV8MIjxN4pzHxWTb7wd3ueyqtaur3xDVMD0xO+u+6MYY0JU
GDcwNXeLj6ah2ZyesxJNdMMTWeywnUHrssTpJp2GGNSS6yEGGQaei/CyiAEqoiZQ
63BJkIOvvxX++/x7FhJeGmGl28jwXfZ65NdE5eNbQX/TSRDNs4tKL6MjzU/qKA9J
G9Gv//DEz6SMG06JQzzwMtiLJxuy+uQI9AGYGucecMiGyT53uBh2fDgmHQSxeLmf
oHs4STkDsQ8=
=ccDN
-END PGP SIGNATURE-

[PHP-DEV] PHP 8.2.16 Released!

[Pierrick Charron]

The PHP development team announces the immediate availability of PHP
8.2.16. This is a bugfix release.

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

For source downloads of PHP 8.2.16 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_16.php>
Downloads:<https://php.net/downloads>
Windows downloads:<https://windows.php.net/download#php-8.2>
Changelog:<https://php.net/ChangeLog-8.php#8.2.16>
Release Manifest: <
https://gist.github.com/adoy/63bd01f657b3f5cd6e5a271494349c68>

Many thanks to all the contributors and supporters!

Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.16.tar.bz2
SHA256 hash:
2658c1b8935ab6b53a7f209354602761ab07066e66920bc472b8815fd1b43f71
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmXLibQRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adxXfA/+PLJ1Kxs+27pSCazdb5isNZfjLxtYyPA2
If57qMuI+srNPoh6cx/5syXQH5kft+TetvmplWRqk/0FugfvgULSEZSOhB/CKHfC
BjhzMKZB6oB0BSTFwjFQOmbpJ7RuvGERQeiQn5/uKxZbfgR18div8iH8Rg8l2b0X
Q1Eo6qYY/grhkWVA24YkV/o4j5UV0pZx0nFRGT+FUYx3tTBteO5tXolU5pyxnYS8
kbjgd6EeLD1xjel3SpPzGEq5SIx48q1O+P3+lqBMbV/20i2M+TPOAOLDIGgJQJP/
P1tsFXuQEtoBSV1fj02Om/E7EAd+U1CKpZkbpJQOfshqa3y6NkOJARagDD7v5/ht
3nnsqBGgukFT5pb57wq5z9NvDlEdhWw7ZP7xNkCnC+47empZpki/xDZQDv9k47R7
hiJgXXfX6dOlNr5iZ8y8uryMxUyitj4frjv4qPnl2NBT5ROJ7TWBRfRnfK8zlTuT
sY2N/o3HiCpAKJkT6EM0Vcp4znTr61fUxq8Rx/4kI1FLm12HZ+9K4cUsRcz3D2HP
7pEyNtK0oVrID87K82sh/8MpTpQvw7YEeU4uLWD7zPvS13gi2dOhkVJxika975Q8
LrrPDZv5ztcC3tjClHpL2HkAx7ORsoUEo5t3EtIB2/Y41vfRDX3wRaV22f0J62w8
FcomuHBMYb4=
=9X2l
-END PGP SIGNATURE-


php-8.2.16.tar.gz
SHA256 hash:
62a92ef7c2c6f44b12e459d8f3d649aa8ebac5e05845f7479fe55a7580cd2dd0
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmXLibURHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwr8g//QeVc4F68NDhtPKLHrBIXbb6rPhUSupr3
ZfkreFVJJkulwLjE+QtJBh0ZSP+NhDvyXa/LAyZaO/6k7tAga1yt2P+zcQvhZmdr
LaToJBAIDZzy1vA2/gHuJ3bNWrScxBSipo/UUHJAOB7LwMNeWSgDQ1wX8mDg3Odn
cuNVinAmjUoL20F5amKX2fnr1Wd+T7tChwH0DyyyH8eO+94LhBZXcxAOMXkfjIsl
MUAVJdXucCEKRvqyGbNwb97Il+RiaCbqk0i7JSvAA6avQL0onfEvhVdFAAfxoUb4
cQYdn/PkPhXSFXRAEmcV48d5mA6v4N9qeEZ9+FhTKlE0dCHmGjeVS1eYSFFQveU/
d9fOB5TSebIuLO5ecCq+6IO59T/nXPkfVyJ6eNWmPneAyBf4nejFesDZhhG+Ti7D
zQmNHHmU9Gg4Iw+NC1xTl1LOb62ZAfCU7ZIo02woDN3bADplIJDF+Wc8XThhzQun
/kdMA/Ke/05UWh2W4YUmwCc2wlOWnuznx6PLPHm7ccXbOoSVQajkQB9fPtVXUdez
BxjXJa7Vd2CegavuMqIp7F7b7+2zAcolLa34nknMuEKtgWVbf6FiuPAr2769P3vT
m/dOqtJn6uSHWHHQk96W41t8COvjxNdr8zniSuuKDcsVz84lJUEGYPAujRpsZBam
hrI6XY7LgzU=
=CWTU
-END PGP SIGNATURE-


php-8.2.16.tar.xz
SHA256 hash:
28cdc995b7d5421711c7044294885fcde4390c9f67504a994b4cf9bc1b5cc593
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmXLibURHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adyPvg/+Kfs0y4SRHGcdppHynDIZQhPPqSsUHbTl
Z8DVv1e9KCIkFlMboc47s6C2VcPj7eMdnPUr9MYG1JMlW7Q8LzQMBNY9CG4PiWRw
dlXnYxzi3s7xAkyZZYSmrd08B84SWpz/h4UhuC45vNoKDL4Gda203GX6Eprv2txf
Z1EONizVvVaiLJxEj5r9xRWsoJ8NFNDU2wBfdHYxVEk/G82g4mP7uyjnXGxjHqQN
2qPwdVO/5MB9d6gQBrOYoO+S/sx5fK8UC2bElMREbyAouygx3yHBockguTs4Uzwt
h+71t+ehJNxiDROpZH6ufoGeZIkkaZRcWzfMCBvrwYckRuBY+6MHryupqFYmfPni
P4HxK/noLWtQwvv5lMiHURWoYhc2pGDoHt59D9oZTtTP9D1u2PjGO0e4cyJgdE7N
2gA+pRQxdDQceJDHPSDyMEIpkfb4w7u8d/l8L22Inizva9YpuFWKyXeb7u0mQFJg
32cB/mR1ffxYWH0hCMM2aWvr1op3CrEupGdG/FdTnBB6dD4LCUsXkuROP1yW7Uoi
VjAn/wg/H+CfIUjuKZNxGnRjvjrPsGxfx/2EGU/hRabEe+/cRQXtHtkaBzHbcmZv
K6SHC27bBirvxEHTVRGGLcYJX4TU8z4S29EjjA5pyv2NqxWamce0HPNEahWLJ1xv
bjxMi6LLmV8=
=25i9
-END PGP SIGNATURE-

[PHP-DEV] PHP 8.2.16RC1 available for testing

[Pierrick Charron]

PHP 8.2.16RC1 has just been released and can be downloaded from:

https://downloads.php.net/~pierrick/

or

https://qa.php.net/

or use the git tag: php-8.2.16RC1

Windows binaries are available at: https://windows.php.net/qa/#php-8.2

Please test it carefully, and report any bugs to
https://github.com/php/php-src/issues

PHP 8.2.16 should be expected in 2 weeks, i.e. on February 15th, 2024.

Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/a93b3f88ae9a677d7ef8c5466d312e14

Thank you, and happy testing!

Regards,
Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.16RC1.tar.bz2
SHA256 hash:
c5eb24c5d9df553ed228ea1fe8596de0ff70ec1d50c34830dd7699e05452691f
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmW5N20RHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwmrA/7BuWEUwmnFbnSECGZTVMR60gScnT9unHR
/5q6SUWPBkVXQ5vqTa0KDT1WGhHOJuUAJhg22a97+khYWC7T6HnhpnJlKEl7+THS
ajyohlIBdHMWITztHPS4uDRYoLsN6RL7MJXrW9MRzUmwx/cQJ03f0xwxmeQQP2Kj
f+IGQTTKuwTRaQTX2PivjmUCw5qRr0MCyb6H3MmGD3coN21TA0nPYsDNKBiZyozZ
kSmLSx9MlurWzHss2ABnkZzw6Ic41XggXSgqwNw5lu4qtCQKx468RhyrkXwp0R+Z
uieHItJ2y6Gp0Ah5ne0br+y7/W3dYN3ALmyKiJCRzCiMfWTxgtJgaMswKCkFDkNC
bt39vPPlkqr3CM+Tugl3u0O5/nIQPgNzhjkEmaWN9AjEQSKOZfNtjBCyDsqfXpRi
ZAyCaqqfqeNu8enEhV52MXm3aOdTpGDaAwVpGZmREeZPTUt44XmRwMc55knfD+XT
y5Fr+UK597wd3gKoqtIKrnbZv+MkAXpMe+GiMAeFy77yslJ440k0e7e291wC0Ne2
xnAADVmefBSIcQ8sG1G5peeL4Y+lMStg7kErJPezTnYkWQmSTIkL95Og7J4rOFwQ
e3/sj40DYnRTfjUrWD+ic7BbwOfdxV8pkMNuCxZoCfQ0FrNRVITKNHu2kagztc2Y
BNE0tgrg51w=
=8UVY
-END PGP SIGNATURE-


php-8.2.16RC1.tar.gz
SHA256 hash:
a461eef7cc89679f9fe7295782a402848f1a91596832c7736165f63e7d127156
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmW5N24RHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adyDGQ//WRMYml0sZ/z6po5ZI76cvlhxG8K7rDyv
i5cmJkN2OZ2HUuqEU0/m0fcUWiAfC5Sjy6Ttp2cui1DFGFyNVziaU340zEzzr545
Y5YXY4cd3obcam0JKPlvERqHzLzVgGy6Mt7FOwYzt9ndi7x3oe4/kQ4ieSTzUhdn
d2qlnBwzczBwOlLMn56zWn2watmcCQEIOmVNdmOyCvAI4ACbpp4wlmbAy0S26LYl
kVet3CKIMuxTt8Bf0ykj9aEi6DudW8Y0bsv6Jt6nTiCe3U8YjW4ywcFW9CVDL1ny
SO1L2rbfhqgDjpxFtwVDGTILPq8Ew2Ip2YoiGRfBoq8JSL2teKDhoZmQdmYyLVN4
wAUcnT7N07Su5E6X66ikv7GKMWy8JQv2TsKz7g4ZQj10lMVHYe+ap0PAUuVdNPUF
CymogsxXH8Vc2f8NizAeXosVSuyOrnbe2VzYKUVZAhAONeBrtpB6RtdWzmOZ1Dpa
XXGAM15D6kTtHYjr4Yfw+t1kbq5HQ3PWwbAg6t8kwYCUcGWlNewWZNEwiPZIn2Ot
3KK1RWjuG14315kuCBs5mwFiQBcFkxs+rzZhM+xi2uVwWRkKA16k0k+f8rqfcYzE
MgD5E2rAAFrxi5Mq6/6+lZD/JW2WohYRn8tMlKG1q7v7rH98f3yN1oow6VwIrgj+
KKbjXGUpRqQ=
=HbAW
-END PGP SIGNATURE-


php-8.2.16RC1.tar.xz
SHA256 hash:
317546abd060c9ee0169b038e7abe40c873c59e9f52ff88041100897b5ac25c0
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmW5N24RHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adxCzBAAqzC7RZw1Wzuyv3Fztyp3iV60AvbPZjiN
q956rLQ8bav+LXLKtRnWmvRADkHqXYkYOe/TS892PtdvUr/qDgvMbzKIO8zU1APz
/ptaRdlYwLc0bnyBVhco88EbNvnG24hj7m2BuzjnakLgyntQSmqrVKWZB1XA6I3c
Ayz2GXRo0dyOj28HeKzFLWeDRMVj713mTRky7sYhsa7HD9AszqJGO+6fa3L3M6Yk
Dlj9ObjnDmwTtkD6cXnd4TS9iz0o7cX0Nqj7qJaJYL1cIT9TGC3A5Z+Qhw4tU2KJ
VccdVdukrxEGouu2F41ZVSvnmsMYGDCCZ8WIPyS7sC03bO0XXrF23JyNdGg957Zm
sU8P0FqW69xkpyORkjUkulpyiw4m12S1AWJqhp6T8JlgkMRqI6HI0FMLFGDGA4K8
0EgHqi458hTnl2hqSaoy1ohNNfxASeJFbcGeWEMGP0GGEhsxMJImuAh5QYbPUkpZ
CVAqwYgcl6OCxSOUWpbgmOQGPXHnY9NzichBdwQ7serBqwIAqH4zbLIMuoYYihy2
tVKDaRyw+JgN8+nkOem+NygaiZvTSFHaaXYdpv4RwLf7h48drJ152/fBHGPd7VDi
SJJX3aInwWUiOEw2ytL1ZzUJJA9cc811rY0N1CH62QET+XVbnDJfBWvF9GTCfPEb
r19n3Z7DQAU=
=GR+8
-END PGP SIGNATURE-

[PHP-DEV] PHP 8.2.14 Released!

[Pierrick Charron]

The PHP development team announces the immediate availability of PHP
8.2.14. This is a bugfix release.

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

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

Release Announcement: <https://php.net/releases/8_2_14.php>
Downloads:<https://php.net/downloads>
Windows downloads:<https://windows.php.net/download#php-8.2>
Changelog:<https://php.net/ChangeLog-8.php#8.2.14>
Release Manifest:
<https://gist.github.com/adoy/643bcae413fd13f57990cbaf9b615d09>

Many thanks to all the contributors and supporters!

Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.14.tar.bz2
SHA256 hash: f871e131333d60ae6c537b1adddbc2aea54c436c562af986fb8309c060040b9e
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmWCifURHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwZNw/+PrTeZpeEK2hikW//DKUyzJTDItDXarlm
K+FYFbvqbtQ1i+0ydjtEpWi8n3oKlTWo3KrV2Jjk2ImwoO0dv0DTlOgdRHvt40U4
rSL9Yg3ae8QbFAOOVMThcnEEbrxnXUbMyuEkb9j1ubgDDLZO1Y4+L3RZwj9llMu+
5FeLM4pz2rmpvGCFm0nhpv5MoNvPpAIRwSjLijjRqS7ZuHN+0lAKXcg24XKXHrkN
9/GdX1QJFnWBOzXIy1S+COmfk7TEF+JFgGdkj4YevKrG5kgLye3NyymBWQV/dpeW
F63oZjUQwpFb3Vgo68moUONSNs/V0OR52b/Z++4o/XXsfFbGTj/qaEndqFq5DDE8
j0rwKIhoZm2SraOTbQYexynkAk/r9hcNC7xUY2rd361LLwpOwsQwd0lXIF6BCSqn
TV6JGeKnz57FwwC2s9NTIaV6XXj7fs3UVigd+xh5fghHxjX2VHvKvj/Rz2R8Ljf4
5I6LjY+Ss//MA7YlYtdfUfiJpspRMotUIOkEAU4J89hv0Db6MbmP9eE9fGE87PTX
od8ABvWZq/I73dUS47PeT+P60qvwrtXxsTBJaC40+Je5iP8v2BTmiVvVihcgMmG9
JW4G+BkjybEP9JE8LMMhmBY1SXQz+KZzIs/Asj5LaZDHn8HSnA7byUILbjOjJ65O
gJkj5lxrm84=
=B+1i
-END PGP SIGNATURE-


php-8.2.14.tar.gz
SHA256 hash: 4c1fbb55a10ece7f4532feba9f3f88b9b211c11320742977588738374c03255f
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmWCifURHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adyMcg//cKj1EDA8kWwOlH2yIG0zTnSQrYkvrayL
0WWVfokXUYZMEi54lyOIBAyps9mgF5PA+aAi4EuU8TR6nMRouuFutAWvjVIq0c14
UrSo/Hy18snNkWQC15TRc+ReWiV3aSsFBX05RTeRS5VA//FD3wesU5YWGhRO+Avt
FS3XSL3qmvp1/meGfJ3FBZYIN/rVVOJAq2SZ5eLkwx3ayN++ebvGp75WeX2ha4FB
k2bZKznHyo0QhVj1/lKxLZSZ1i/rrALTJvUvLT4faaMLWOok/ru4u5WQ/YnmyCWP
cpUbyzJr7CcCY8GsWmK7E4jetlznmENtAIOUiJOGOn8jfsYZNMeLpOxnWmo+UNOq
3K9w046Q94naZ68wHZ7Y20m/AhZb9q6gQyWzUPEZGBz0JFsGxV8LxUuSCB72PK/s
jxmbGrJK3/g131IBteV3F/GRaG8iot8AV5H+CXt+iI2Rhpyyutn2dKVIMAmXHHRG
wLDaJfLW0uXGiPZS2+xiTv8g22dARs5fctkBDoCdl5bu4W3CT7xiNNx5x5LjMQwM
KCo0Xtx6D/+O9HmLgUKh6OqIU7KDvQS6O7uu6QsOl5leCr337aixZo8gTiWay4g+
F3JFlY+oxL91pjZCbr+LFXbQPa3T2Gimj3eOL9AZb9VThCDKV8E2Zp8J6yZgvfzH
80XL4TXqubQ=
=N4f8
-END PGP SIGNATURE-


php-8.2.14.tar.xz
SHA256 hash: 763ecd39fcf51c3815af6ef6e43fa9aa0d0bd8e5a615009e5f4780c92705f583
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmWCifURHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adyMRxAAnANtD2escwXW30uVQJQ8m3akBUovonGX
1XklHnNE3aApB8hkACCZa7bB52E+0rJRU2uhMXMM1l4aUkuShsD5BLz0oqv+xJcL
LLmuVGuVDifMHduyTb+7IN0Dm5+ET1zlogQtP/NUFfen5vCI8px77hBbqWtikAs7
WhDFFQg2HQZ0xIplpZr8BcMJQ/XKtLZxmWLjidV4YstndRNEgbrQx+ed+c1tDyEi
COUqt0UOqrouMZZYihyKcEMQrXLgGXHUct2/7yL8KvDv/Tjnwi5p1lVZ+DdIPw1Y
JajYp9e+jMtmL6hztVkok/RQlBQMUDn7Nh8FBH1IqYXPd5KshF6zQkWMTJ+YdyC0
qk36BxOWgnaDhIQBPIVdryVDFN+ZJ5Jil2kSs0hWOLr02gcDyuyf9J1OVa8QQp4s
NT9I+ljeBtFm0p1EH9VFodJsN1xKSqywzn9w5Dl5e3p5vS923V6H8BDjExytuhN6
S8zfpI6GJFmwIhvWB4BAlcsXpmby0u44QX82Hnk+QMkSfdLjQRrbILMWLt+2nE84
WoMLJ9NthB5IrpejvaSj5gtsLubxD2WFaDeq6XPOi+HbUP3ytV6vSBHhevWbhghR
JSMNLogDJuGcHnkgfZKQGhD8otCMToEnj6/GSZEjty2ywznVcy0J8mQbTDT3BnMR
QtWwBICwi0k=
=pStQ
-END PGP SIGNATURE-

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

[PHP-DEV] PHP 8.2.14RC1 available for testing

[Pierrick Charron]

PHP 8.2.14RC1 has just been released and can be downloaded from:

https://downloads.php.net/~pierrick/

or

https://qa.php.net/

or use the git tag: php-8.2.14RC1

Windows binaries are available at: https://windows.php.net/qa/#php-8.2

Please test it carefully, and report any bugs to
https://github.com/php/php-src/issues

PHP 8.2.14 should be expected in 2 weeks, i.e. on December 21th, 2023.

Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/b0daf2b42dd7aff34f2b611619dc3adf

Thank you, and happy testing!

Regards,
Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.14RC1.tar.bz2
SHA256 hash: b34d001d7d2d1f59e48441cacd8de10c84a140be3b3659ef0a6697a46adc66c8
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmVvguURHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzhoxAAhzDVAjkFw3YHIVR2c6St/hJlQNPn7Blb
KMagANR+cTdyLsV60+nrHjvBLNz5EYdmjGwi3jU0H2oVKWetZSW3H6Afg7p+FGC2
MDAifvhvhH9y7ikwKixTmKG2QdNNZ0FRa0g16cnBOwS1vkPNOo+o60mzqjtBXCbT
Ekg6AWaP9/Qla27terNXrvB/MDzJSD6g48J+EUJ6Jz5Jh/BHdxxE+cQhFQ1T9KBF
ipQ55BZ6Uo8MCXEoIrQweglzLAtpFC3gZRU6fzrS5dI8K5Hpr10jl66aqFO7vQHF
ZtnBwAg68hqJtflnj4s3Y52cIBvRhXo8IqEprM+bUUYR4bV5zI2AIEW4dNbFb772
PB9nB6fR95WzQCfkHnUI+8ewpiH2jeFfqCU+4qyeLtky/T5FD2jJC2Y8eWrJcz9n
Cysvyu2WPRiM6rQ9D4Tl00vaJtWJyyZuNEwbiPfrkL3YiA1Y73NFA6H2ZuZnUxzq
gS6R/xlJYU+MF8ef2JW9sdrg21b1yPmGiaubRnoVQPlIFcImd6usy6awu9fvp8fJ
V59KaA9KNvkQK1RsswlBaVH1iNDzq3Q+TwzWAg1qHPr4mAp7mSQZwZb17T0xfdtR
0j/W86FPqrJCSVP/8jfk/koqQ0/vZFVRn5G1hSiPk2g++/XFzPAkpd/hjPod/ROs
EcJ8kpgcT34=
=TMC5
-END PGP SIGNATURE-


php-8.2.14RC1.tar.gz
SHA256 hash: ba2df909626976aec27341625c69841988b8af48a6fafd53014c0ca6a366082f
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmVvguYRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adxE0RAAovl2o/+kJOv0LM6Ef1jnQMRnfx0DvV2Y
2KQO2qQITKQhav9Vm8thF7nyPfMK2SZPRiaWNiMRivlEq6MDz7noDH5ItUYoJZS5
YNmwCHcONzJLcqOLgRMi/XJx6VOkBUCtuijnKq+TNyfFU5CigHkjCmWgSWZJBPHx
3+netaLwIsTGycmw/TOavgd0raKXuDhOSnAqOXFwxyS+HAlJDwxUSRD5i0bryTgG
wzjAB9knvIz5xOsDSJWqzKTqYZq6EqeApTnQCirGUDyDFtHTdjrcg+2Z84kFIpnt
8HDbmpgqHJpBFUXHPYrkHwp0TPw+BQbSv2UxaUzB2zv4dy/0U9BrZkyT9SbCFQdh
xIa0ki/1PizP2JDShAN4GT8xdH3/TnG6uRvx7b9U+rP3Gxt4lBf5CxGwiOQBnAxs
yR/rHNe8PSPKFPvMRik60YYXQBZgHVc0dKytUBd/qsj5t8nGYAiGvKleOdiWkoW9
L5z1PKM1i/pq9bljUBTTh4ph3QtctRzoWraL6wpuScnIE+I3u7+6IvkAEmer8t+4
s+/DcYVSBNQIBEToElLu5JEKWF6N7YbllrjMAwbmVzFUqBiFJAjQIzu3tqnxY9zQ
54niIP+06Fsf2Q5O+/B6Yw8F4u1JsIbT1rGRWHDluN/ktgDSrt8+Ic1FP1gDLtn/
hwcthLZV5X4=
=9/S/
-END PGP SIGNATURE-


php-8.2.14RC1.tar.xz
SHA256 hash: c1677fb15c9bbdedd003fa29d0b1cee2b6706ec8cc04be1e6d01dfc1dd174199
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmVvguYRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzyKA/9EoEZqQ94PPhhad7UhYBSV8npFbslNuVO
JBapvr5ywxfWJvgy68iPmRoDAmG0+EOy1HDufEGwho2PSAVZHTC57yV7eKnHeWLI
63rwEwfenfu5Pn3biWuGxJEJnCb7B3wjLdhqVFiLJ7XLOl0xAYYoAsMOBIGByqvU
ET/1Un+uWkrsPVfs4bE4H9o9hgF3QHqqOU09e7jTVafqR4Q/B7rS2YBKANK5wDk2
NtJ1o9bA6/TqNlMnye/v+aBdsKgxOo60q/YsfQXgopSDVWQra8A5CcNcSwuA4qoa
VcK1g0MF73h4eymfhqjkEqeRtGPHR4L7tNn+zLSlAzjSyJXiRktyYZuuAqHiyu0T
SaMQBH2Fxj9mSc4j0f/RCjw4NAhofu5bMoj0RmPL0OzOzp1LtD+BL3L645iYA92j
g1TMJBJnrk82iHo2rwHAvk3xZVoz3dRBpP5FVeTuz+1FAnBqoQql85O+49dwxZNU
vwsZEy8+lHpKOjbIlTjfJPGbQTKIm1gkBkqY1+S7NtdVS68q4N/o1x3IPHMc5v3t
AyYJB9uery+95QxmW/CrZnL7SlxCwfNWS/13q4ck3fPKLk6g7+fzCwul7wcsy7Az
wTY4DS5BKSE/GqfoZdQNjMMZlxEsYUOQDYh9ZuL4vF0YytGGFQU1MPbyHzRApJ1K
JEsWYHkO31M=
=sauB
-END PGP SIGNATURE-

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

[PHP-DEV] PHP 8.2.12 Released!

[Pierrick Charron]

The PHP development team announces the immediate availability of PHP
8.2.12. This is a bugfix release.

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

For source downloads of PHP 8.2.12 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_12.php>
Downloads:<https://php.net/downloads>
Windows downloads:<https://windows.php.net/download#php-8.2>
Changelog:<https://php.net/ChangeLog-8.php#8.2.12>
Release Manifest:
<https://gist.github.com/adoy/6af8976401618c3147c171f5be4bfc89>

Many thanks to all the contributors and supporters!

Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.12.tar.bz2
SHA256 hash: 704325f56b1b4c17f9f951e1ffef5c64e148896053f34e2626152cbaa2f05893
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmU4GdsRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzVng//QBRDLAeps5zpp6O7tv/6kMku4/ohuua9
v7bPN2WxH/4bPQ70N21DDD2B9qfdYwWBnbckS/u2SKhLhI5crg60Ni55tCrEUS6l
k2mR4CuVYJRsszhLrZ7Jg5MRxqYwdNG0k1UoGIgF5X3h/XJXoDWZaJ3eREgvZjWF
ZqXJ2gawG1OUapXpUAoxFyLhN56kR+LckxLJWjORDm80aMjcdZ+ei2bifsvu7Sch
++k9lhbNvkR2/CFX2yNco3WcqSwB9PYfRgWJIMROhhLT4593f9AS3hpuGG6vyyKK
esk+CfTN/qRNoRdMoenPDEDWgxpg7Wu8hIfWEDJSx1qRKxz29vWIzHiwXq2Ajl4e
MATtHP2GHNdCVuuLcfIR9mdiOrMXADoivF4cGwCv1lza2UwSv4bObNZs9mLDre+s
zJs53996Q3UGvsT7dp6shQ+dQxDZpFGwzAetBGtO8PdcBrlgVfcA86Q8xSuu5DjJ
YjwyoRqF3FlI7re0MEIiV9QGNwScCyMK8i0scV1L8BxicyaqWjkA8XDVwL3Be1WP
KNNULcBYD4BvMN9Ko4B/t3otxYRvcqjEY5aJ/KvynhnYLH7my76UvgmAkymLQkVf
9mDeNsblgg0POYrdaMReOpnfaLdDGYfQCCJ13DLi5CvJO2wZETY0Z1q3SI9ntenS
iHz9CittZOQ=
=8FfW
-END PGP SIGNATURE-


php-8.2.12.tar.gz
SHA256 hash: b2b74a91f5fac14ce10ece0ac210f6f5d72f4367a3cb638e80d117d183750a21
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmU4GdsRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adxOnw/9ExNiyLrntt0SQF3yHm8dA1pRNXYpx5Dv
+KRnWGw47Du8IBpFKeo/eN1FRNUJSNqQoeE80Th9PF3IgGXctK26PlnsdeUnpm86
wjFRbNY/RLoa3L6bjkjtiM3cnUlQ5LwJgxGNpyfKJKHKO4E4EgiSKT5OdqPFhse6
Ig9aVLUuwmc9PrJTGBb2QQoQNTKM+xJ9HlKPYRV/8DTQGX3F5DHJ0+o7JGqS12U+
cZmj3f8YZp80s9yXKkDe42MEQ+AzdGQIoOGbTUWY/fTKCM+RCFkDPSrBKsQamxRa
iY/1VdKyCEfXBcqA/IpmP8dCoQulhG5TV40rO708Sq4ea43Pw2GHIx7aAqZ6VjjB
eVfLcpEyUn7qIoDv6mbaeextgqm6lGJfnEEqbIXPk7vXdYiJmKenhBCZGuCJeAYv
Ih4jC88LlePs+5+SY5BW1cfYABOODHIFNz4fllUwCcsy/zyqDlb9eSaDQ+Ah6Hup
r3+Vt1ScQgFj9xHg4wO4JU5d6Gkxzefb80nWtVSakcsQ6IR90yGO83vzLHW/F7g+
Mp3sH0I8927RiQJsa726Y5uzwMu6aU068PwRVVjg+RddWLRhiHZMet+q3WuRpytC
2yId9WsQrcrJZeLzQ0ztgFWt1sHCX/irMfjYxLHBCK0duAoLDV6e4EMYM4B2OPjK
M1jGLs8f8Mc=
=uSMM
-END PGP SIGNATURE-


php-8.2.12.tar.xz
SHA256 hash: e1526e400bce9f9f9f774603cfac6b72b5e8f89fa66971ebc3cc4e5964083132
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmU4GdwRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzuAg/9Gb7AOR1WFqltlPw7WQvs905nUxdhLYTd
MU+UTWW16LB7sq3/D8K4A5mWD7KVsQ177ngp47NUOuGEi0CXMriT9ztznsCKl3Op
iHilfCgbuUiOeIcAapwPzvdmnbYkZXoLJQprAMq65uitIIyYG428oRCIeIeh8G7L
3hF/VSI21uNvmMEHC61PCRENPyi2EJG9AbiV9N0pjExo+gXEaGwTQeQujxmq/W/G
4W0su7BcnKeX2BWyUpNZ/RZizUBXG40C84XRGZj1uAtPNmokP93DG9nYuTioG2ln
/IIuwrtAewNOlsUGaWilTpZDjknUYlbHVzkYsvVcH0g7/IkNsEzoSGHz7LI3BKSQ
pmUuzL6GVLwGzVCMfcM3UjB3MAYtZsYVkB4ifHGMCIjq/axjt0ilurnMhV56hX10
JiGzSsTg/EYTU3gy7n3jJPLMaes2SHBcg8Oc8aaOsl/0i7mFSzFDLE8Fy7Vl4NEO
XX3qT6dypN8uR1nlVlcumQBypEyENWp4+MuZK5fIa83Jj4BKe1JbYc6luNtjrvOR
XKPQnrGsqMPr1zUzvlYvmVR3yK0cVUDyi98M5oq6Hmlmz+DVLi+51S85mZPEOXcQ
5YMCo1oHjtxKrVBufnkXwb4xlH9HkG/EVXrEBccTMqdZGBby6ffzQxm9OvqV6NDv
3mnNaSVKekM=
=7viG
-END PGP SIGNATURE-

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

[PHP-DEV] PHP 8.2.12RC1 available for testing

[Pierrick Charron]

PHP 8.2.12RC1 has just been released and can be downloaded from:

https://downloads.php.net/~pierrick/

or

https://qa.php.net/

or use the git tag: php-8.2.12RC1

Windows binaries are available at: https://windows.php.net/qa/#php-8.2

Please test it carefully, and report any bugs to
https://github.com/php/php-src/issues

PHP 8.2.12 should be expected in 2 weeks, i.e. on October 26th, 2023.

Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/e7730e3cfe0c98ac6c2f471149f80eef

Thank you, and happy testing!

Regards,
Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.12RC1.tar.bz2
SHA256 hash: 29f6e09e47e566da02e198cdbd486a4a1b658bd9af7df6db1b294c9409ce0b78
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmUlc1MRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adw/Lw//Q3m/tTV5DnLwoXiHFuP0a022HVooPKc+
vVEpZRKJLBRTHrNKqsstdmj6R/OHANwy97gh+zZ2YMgKM31NlYGfBP5sLI4m7ofA
guS2XALf0iyM/OJU8vJSiD7BcQM5YNGtAZlize7GSf5glWYBqtVPWH4Pj6WP5AMU
1WH8pJ7/V5W0YYuhN2V777nMiDO7ph52uXnUQdYu1Cu41qn8JIiM4/nasI9nqtSf
JtKjuzMF9E00I57mNWoTwnuLmgO1ttYnOgF2/ET0UPAD9z01wRghgyfO9TYN3gCP
25l671dWJH9cRrwV3BjUsc64GHDR7AzywUqE0eLFL5PhjUYBZfrx9055kvWx2Xv1
IEzywalFT1Bcy2GtJkywfNdFsZu9zEjcV9kmQucqeXK2itf9NQroIUVKVf4DIHxU
LBNKSl4mqM1Rdtu4Uqjw1S51B4EOA1pc6wMcCKecOFcJTfc4OFzyDx7/ATHbJWpQ
dXGio81POWDtXG1hFHjW0ubTSE3mTTXbWYWySeaDQSm2976QBeE8qSv8mxGNwPIs
+q0qP5Ft4f1rbqpRRUYsi1lMiHaJ0WIi9tG08vdu9CO8TdyShaPesn/ifA30FrOB
spXnn5fUmKmRvtYxUvrYjBZC2a0+rLcVmheyMxe/a6kJiWTJHh0bj+7qM4NxfrRH
e6yHtTBFNps=
=niSL
-END PGP SIGNATURE-


php-8.2.12RC1.tar.gz
SHA256 hash: 40ed39c34cb4c4440226ac6a4e2b4143d1ed4b1f7ae60c4cad47b6a0cc60f1fd
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmUlc1MRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adyTXRAAtM5g3YUKzoJLqJyQLGsfy8RsuQS61JO9
brnIZ1/OAS+RPCLcrqeAntAQGRT49tGZeKTwJ/MNIk77nV+t/vXAA3m/hZ4E17GT
9a9HhWduhrf7GBqnqNg5x3g8SFOaxVHQKc7wRKmY7vdv1FsCAJWQxn+ooLDhtEn0
4shVVO/g7WilTErb7x6mJsswRUu5gxUQIQOIoJauJq26HQlaF7eoLfBLPWJSnu+R
H6glVgl8TGvIqQW6C57myQb5y3SoQM8nyXGrZqt+Xo1D7DUt5bTHxn40L6fqusmm
/cXJrssjj8XgRYouiXk0al4t5MS6eUduwmK3ym8dQuRm2G6fweom0oWsRAJRwEat
TnVCBndErHRNadjSaDAiZQUe8Jm1/Z9DLHuebCW/2HOCPZk1CdHKZ6TzNHbMHVdH
h7RtUReVK4QL1nyLmNIVZgnFf/4ZIv8eV44SK7bPSVi88WUrU8NwRZKQaNFco1cT
ff/5afxdnb70llL3MD3uyEHJ3eTfBoymgJutinpuJqdGrv82yKBER2nxdMqmSoxT
hqrNl5yobfgaAvqBaGPNk2F7R9NEE60UGiqp8GO12OdHvmAhiKbsyXJ5E+IE7iSN
PzxTo3jcFWCcVDLgbAcrsfn5ZhPzySJIoeYMBrEktpu5QUAoRhBd5kYNBOzYsIbp
sRdxd6RoMP0=
=CnKp
-END PGP SIGNATURE-


php-8.2.12RC1.tar.xz
SHA256 hash: 413b91f79227950c109c544465c3062766a3940d2f0241fef8e9a367c1be65fa
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmUlc1MRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzqEBAAhzbxNF+UboJ7wCGTzQmFSYRIMCoua1Sl
5/r89aHNKwFSEA4auEe71S0Y0A/xl1nf1wDn3/Pv245weli59xdx8hVBuf25biv1
s4nC61Z2HwVx/5hJvvK9GMwMXa/FlevMysxOhvPO2dfh1ujV05yHMeRvOu4mUnh3
q9rR07WPeeVuQdQxKDbaTFM+2+qgbNwxsgw37n3ljHEQjbpJNYFpCZMK1G0c8y06
3sAv68naLUPHZ6j+jU/cQrqWyCJIiiYniQXkd5mNeQsngbJXFN/IQDTQXF6StO4g
FjH7NQclUPf/4UDpuBfzmLleURw8UIC/H5SuoNj4xgQTE7q8eWMF4BvXZnkPT/J9
9VxmaBMuXIJlPIPDbxXbJdNWzENbTPe44LlXvip5sBQa/49rQfcTKC4Hvy618KNI
xNZOomqnk5lTgh6xEklpwPjr8E9SBrrj5Bul3TCq+pr1bx9fCuZw+MjwP6uWQASu
vEqdxnqwkAI8gqXDqCNmRvFwPVJ/7x0xPMgdLug/HvUlqqZSa+EI6Te76AHN7aGB
gT+t5vCaq+aNNr/KM6DbQuwGR+arJDe/JrqbYmrnDd5PtVGwKujN3CMkKECSrnz7
IZiWcO41dKO/mf061ACuC3lUtCPXgt2U0SKBqGSRrQUFWD5nKetP5BchST7ea4h0
Y2Zh5BdLLpI=
=YZ3K
-END PGP SIGNATURE-

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

[PHP-DEV] PHP 8.2.10 Released!

[Pierrick Charron]

The PHP development team announces the immediate availability of PHP
8.2.10. This is a bugfix release.

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

For source downloads of PHP 8.2.10 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_10.php>
Downloads:<https://php.net/downloads>
Windows downloads:<https://windows.php.net/download#php-8.2>
Changelog:<https://php.net/ChangeLog-8.php#8.2.10>
Release Manifest:
<https://gist.github.com/adoy/a2c338db8cc96297f20bfb2c89a98587>

Many thanks to all the contributors and supporters!

Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.10.tar.bz2
SHA256 hash: cc9834e8f1b613d7677af8843c3651e9829abca8ebfe9079251d0d85d9a0aa3e
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmTuD8URHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwGGg//XSJ1xr80ka5V2zHw5P8BcAUB0mxv4faS
+gP4q6XVXuHjdPaho9JgKRD/nNyWSAeZtHl1slswyWPAf+N1V4sVttZWIlwrawql
D39jadRyFPhmJJ8R/rN1O/7YfQgGvPZYB8/4ZQASX5x+UA3MxpU1QxtwENjyCeII
QtH5ZPKM6TJ0QSvtBDa6II1+aP1XAIeM7eW+CLrNk+pwBDRU8eCQj7bGWyzgGdL7
smSTt88Juh+HJDdugO8B2HYbMw+RapslALP1ZoimsLdbwdIq3hxJXFaLF0/ToeC/
6ht6q2ETQqlaq/zveeDfokJN3xzpm/c8xKjx0yX/2ZLPiBzz56zGOdKz7bPWPqSL
1Qbg1Ib+v2LR/qKvYQz/6UvjcFA9RUHXiQd6jJ+ZRBhAnE6ggZDjZd8z6g7hvbfM
0Ws7tKIDquNytA+73OY0Hz6sTuDyeaDsiBB5/nmj3lAHRPsCfTEfM9XB1LVumVbb
dh2oUoht5KTVPUuCuVTOZYL2xzMVNL0Mm56nFidoDo57htEdif5OPATgt1KN0ytu
Trgq7xWGYc/ApBOBbLCQ6kIQcQKcAIxafDu08GPHMaON4k2Fm+XPis44t1QG0UsW
OZ1M8Qg6NcKJdwrQdScvFrgeflhGn54XMpp7q8f9hwnhrmFoSfu6F4CJkU/4qCEI
vvPyTk2cWjo=
=zAXK
-END PGP SIGNATURE-


php-8.2.10.tar.gz
SHA256 hash: 7e3e277d6eab652616f90bc7c75991179c0512953933ceba27496fb5514f7e78
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmTuD8URHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzkkg/+Nbd3xuH0VVUOCkZtN5KgE+BsJqkoDcKU
WoPnLAXw6haH1wYmDZ9prnPsxMUDe1lwnW140kH2QYpex8/DHFq3/e7bCJKFaloG
E+U5pLIS1G3eyUkh0oGgbWtjW9CRi74XURbQyvk8ImrPs7AThNsHck3tTXrEyR6d
CP9lfAHkep7Hu4bttrjYdpwNFIGFGqacn89zlu2ilGFSImVIrNOfImcrT/0cj9NK
I38OypjXkp6FxmoLDWv4BD33V/z3zvSpr3TM4uTG4YE5aXCh8sZ08MPHYVSfuOfA
Oh88AYjs0TYylAipQmGM1FuJ41s2dzUOmwpO1v64nkLWTpPoVn5twi+JzV2elZD8
Q/0JRBRtzryxlmkvY5dj3dsIIOw93r6XWR4a+NN0OMef0JQqtLBhH8J071bC+JLZ
d/LRvoVTVp72WPnriuzBISIBEGNEm2MjR8vMw45Zjsi1IJuHqtd8jkNEZRGTkm8V
i864/2ynOsZUIPEyKXVlBMU0VGFKISGJOUu6uJqiibCd8OI20866jdbDyPyVG36x
dZT/Gp/e7A+/hYItUs0cjIFmX5oju5murLKCkGhihT19XQX+6xq1ulZCsp7DwX6X
Y3fuxRc2qd/vDx0ePgYyPLzqXeSGnRoP38wzmdVgFnA4v4Wt9WMNMUUSGZo86u5k
JMeKRwmgXdI=
=98AV
-END PGP SIGNATURE-


php-8.2.10.tar.xz
SHA256 hash: 561dc4acd5386e47f25be76f2c8df6ae854756469159248313bcf276e282fbb3
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmTuD8YRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adyhnhAAh7VbDgcUnBi7Ac4MN+qzqrscpZGKmHOE
z0jNkPWj6z+Ln4fPh8R/L1M8+FUAB1RkF4LizEBN4/gGN/uptdKo19hzBprpwIEb
AfnAwM9WRMsF1R5aoQ4PwBBBYgKdtEdo9T0cfjdXSTN4EQ+GvamsIuLSK3yXa2xY
sKArBrmmXXbSnH3tVLf8W91CVPobGSV0swo2aWDH78pWPJklVnR3qzBw9pYu+zJI
BNqvXdZKJpO8dzK/pCNg/F6NFpbTohMirT2bNoJlgyPRbsAYhEl3ZAJTt25fTBIu
IEAIn014dJnur5i7rX42uNq8Mc/reTJG10k5tkD+ZjZIqXzO++OqHYj5mqRJ8kxk
yrq6avK8oNCFr+Ho2NdFb6SgHih9zdP8W0jgFtq75j+6FoHayd2WQJUqxaPlkvC9
bAH7Kz06haG+vwdCvjDSfPMACysG0fn4d1ofxT2AYXy7ol6FHZHy0N/dRjkrQplL
hYk+iFqEejP172MsxZBxGyNIspwchCn9IjD8TegGLxKwCA6MQId8og5WPDw96hbL
3BsbrYgaJ5rb3bzprcxog5Z9QxZ7LLKdA0lBxCybx4howY5zIq9pGi9wgFWayJmU
TsRaoJ/3FXuOam3w5q43c/jGTslsaRDRribnezhd4Iu027OWU5PG81OesQmjCt9Z
o/Howd/vB2A=
=NLZZ
-END PGP SIGNATURE-

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

[PHP-DEV] PHP 8.2.10RC1 available for testing

[Pierrick Charron]

PHP 8.2.10RC1 has just been released and can be downloaded from:

https://downloads.php.net/~pierrick/

or

https://qa.php.net/

or use the git tag: php-8.2.10RC1

Windows binaries are available at: https://windows.php.net/qa/#php-8.2

Please test it carefully, and report any bugs to
https://github.com/php/php-src/issues

PHP 8.2.10 should be expected in 2 weeks, i.e. on August 31th, 2023.

Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/78c38faa107a4fe3c2901d65d7afb176

Thank you, and happy testing!

Regards,
Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.10RC1.tar.bz2
SHA256 hash: e7bc71312c48fdedae3576cb873c91dad44f9c5c31daee4b4b786aed847168fa
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmTb3MkRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adxqNg/3UAJYvFEodKeTIBo1BUnnMD0/FKYNIa+c
tH02azsjFzOn+eJ6mf1vOsXYDkmjL+PZQydu61+zvAl3BCelLeV7X15UhphZnHO+
inENNXBpXDN1CsGSaz0qlqOLFTiHF35fsc8BDh2xVI1zLjNR1/cnhzC9KqKYXcVW
zwQU5Nua8cm2dzt+RyZTpSymonFzCPIUmq08+9MMsEOtuS5aZiQhiz2TabByVKS8
qjXYPkNzoysm0jO18slzwIwu50naI1WutLaKnamycsYJDhFXLorhsvuyosJSUn/r
+Rlq5+J8jBzuPpGsLollMWJCKBzCMGsbDEexNblieNKUWavYhmpgah5fAdpEilwZ
Gg8uWpqzw/Tw5J6OLKD7xYf0A8IN6EAQ688KJkWfiCRVwNAOCaEfprQcs/gYMIHq
uug5e/jcXn6mSlWpDRn6d8ebE9LjaLxfOlJqAQhyX6Z/z9/ASMtCT4+fRdXAhh/2
0P1cZSani+l1kG0Y+Z6DCMHwGf9qeDpZohYyr0aeK3IUSaFTj8SJuySR42mVFEpd
yw1CjfdsYU0UyIUqrPu7t7mutjtlqxd9yYivIQAkAVVRyjWRXRHCbxC9WoClywpr
ymRB/XDh37916RKR+DZEYEUQrkZ7gInA5zZmmclLH5mUgHSHgRzl+Jp9DO0Le3Bj
EKBuzC8/Bg==
=Xyqe
-END PGP SIGNATURE-


php-8.2.10RC1.tar.gz
SHA256 hash: 2f70729c0fb922b9e3076833bd291f2bf4693c662c608f8e5c6c251675eda375
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmTb3MkRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adySUxAAgmf/35advtuzGW1gxYzxVKin/kksLzu9
CDvXR6QKu1iNQfq6IZpU2qNTSCD7QTm8bnbFLbSvXicHbgYd+MiY9BylZDYFyOvA
VNhAhxRuic9Fq3EHVFgBv/+LSytOKTXeN1QPzWg7Dg6uJu6cT6FxVFW4HUTnoI2W
l0PD66dfLcCkrQoT+WY0v/hQ2E8aUqE1Lesp+3PK13gUkSzTFwsBomx9INaSFgGu
GSbjS9wX+gjafgpy8IXLUSqOWnNP5AXmKgagT8HNRfMrU96Lt1nQnLAifKr/mo2w
vaChxiOS2jODUm0/L46aMtjrBMzyFLGEiGk+FcC4y6S3B5qzpTAPlS1RqVCmhM7R
9q+rT2gn1j9aECmc11ZKzKgICBNk+Buv9fNQ0JpOPz3DJRusQgcSvComBlseKvHc
0vtKMDChbfgObzdTWf+BMtiCba/FZPCsPFmqRJIifpO9OuzPP2HDbUjy8+CKhPxZ
qUps3kwJdo6N/GQnw/Tpohz6dwb4h21zkwwjdnFh+F+kF/dF4Pe8RplSTCrNwiOY
mZrcOsfrwAQvmY0xQmBX8WAtri0TKwYipni60/gEVmkfv8uNcDJsCM1R2nBYdQr1
xsir5boSnw4MQJnWxZMtup3aDwzLO8tpcbkShB+zjx+CGgHtCPj9hhdMxh+3122O
9ATJ4NAEHw0=
=SC0e
-END PGP SIGNATURE-


php-8.2.10RC1.tar.xz
SHA256 hash: 589d7d808b60fc5c69c743fa1dc4658d185070bbcf3ff0c71f3582c97ccb41de
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmTb3MoRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adyY+BAApxzKxKfhg+iEUdO2Fq4jvmnOp/DqH4TL
IvbFSHiq1RPl/v8MHCQ3c+0UMuMy2mMyfxk2smgNN7kWBWhRbCIu7o4wHYz/W/gR
s68SW5mrBBnFowJ4JhTksuBfaXClhuw8/XALJKpB2Bbz0/n3sNFFB5glW6UdoD4U
DPoyNilSjvRay8nMXyss04pUSNIqzse1dOE7Y7qWWZt2EwflNQMCtHgSeSOjVpLJ
saOBzfWzrp8RjCG7+I+f7aZX9+GDGfnPgwU+1OegKYmLXrIsKGnH2i01eyE+e5wH
4nxLbOXp/zIFwnnSl2rU276iRjAGWbdQvxr2+RQEJPDbKtiEaCoSGWmxpF9E5loO
lYTKwOE8KSePdPQRRCj5BiSYZBDzaStNSXHrEr2uH7+Lc4HD3befqLzWBVVnxuaA
a/y9XTAS1uJ7vTT7YW7nq1hjlF1AQUTfRcY/D+x4f9GnlYqbK9yaNOnDVFeA9Ife
wZsvD5MsulHWxzGFHGVWZUfMxFise9tILstYzi470eOIJdef3mSjQYc3dUDZ+ix/
zFcRyryVgUOIz8h5rCNcZ/P2Y2f++E1wSy0nq1PcRS87RAaZWTIoEA1BAtQfvkTQ
T60GYYOl2Yad87NIBWKRRPVoN8KV45CBC6WB5kJytLNH62IepuNEHk9ckm8HC1Ch
JyLdIucIAyI=
=1O3F
-END PGP SIGNATURE-

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

[PHP-DEV] PHP 8.2.7 Released!

[Pierrick Charron]

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

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

For source downloads of PHP 8.2.7 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_7.php>
Downloads:<https://php.net/downloads>
Windows downloads:<https://windows.php.net/download#php-8.2>
Changelog:<https://php.net/ChangeLog-8.php#8.2.7>
Release Manifest:
<https://gist.github.com/adoy/0928b86b24ec5a1bae905364b88f11f8>

Many thanks to all the contributors and supporters!

Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.7.tar.bz2
SHA256 hash: 5bfb2a35c67921bdcadd5c90cb290ad7537d24da113a5e8bc2d646b02de7488f
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmR/pXoRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzR8Q/+PSfv0gDyM/mxvCzKVygvUX8Ii2gxKw43
+lvs7EaXKYo8ydJunwXLcZ3UWkrfOOMR4IcImlxTfqCTz2S1c4i6n2kdM4eI4wFU
xij6+5Zjp0rFylj7Zwftt8LkSWeOPgeLyWdjp6aY5cWaxJLZovqWwyL6NdprYJ+L
yGjh9KszY8BezV0U1zVSFlU6x86o+p79wRkDq5ODmG6dkUQtL6qp3krWj+UJlCog
odNooMM4rJhdT2pjvljUTf0DwXdJLeQxhVlI3GAL2YF579YiXeY68QnSy+425JpS
xYNYqun75GdVpR1QFIy2sjuBSMrY0XGsDS6+61hEFp9QINc932XNCvUF6wkcMkQH
jKChaxvLV84bmItXPqaDqP7JzxU+FFo6z3IDO3OkWUFfm1VaMvEW544e8Ugv40UB
u+E3qx76gC8r1vjk5iiUOilW22VPnf/AJyNDmVOmzjwa/O95fFbUETSKyxR5zp7f
QwNHGYQVcEkbj5saGFwgtyfwep2OQD1nKdF8ToVWIEgYbJK7cF5u2M4gAK0Re/wx
nxDe6jlNVpOc2Jamq8ygJfSap2eWzahsPVIGQIDsNF2yoekI6+ElgCdUcbJjVrCr
3cDqUehBvV5OUjeHq/jEdrLn9tUf4BSRRRrR5SXfb0+Kh+PX0NPFjSpBTUyrwY4O
44rG4sRC5fU=
=UIV7
-END PGP SIGNATURE-


php-8.2.7.tar.gz
SHA256 hash: 7046f939f0e5116285341d55c06af1d50907e107ac2c70defc32ef880f88cde4
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmR/pXsRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adxWkhAAqPST6+IajxD8W63zgI7MfzF6nBDvAQsw
Pu2aoPBwfgUY5tIV7Ud7lqW+4lfy6fKnGJYj5jgYMtKDwY2F3Ec+0Y0FuCa62DlH
ZGSTs7zJln0i4+Hdrcg+UIwAjVQleHz+lj2nFMKMmRP3sX2BRcaBpKVZHguRaoMM
q03aBs24T63Q01kVrOa8M0yqxJsw6RraI9tHRizRwRZ2QRPHT9nHlWsDx16kK7ka
lZd15fZ8szkB2fQcyXVk2AL3LXepRlAf2Atxo1ikiVcp3bJTxae30xJSo260NIWR
okZoTlhj2FVgjERVC+9HpX3UpnlZ2gnoIdcQxEX5lab3SlCvptx15YFg1//9HOig
wq3eDEg4hc238zjyaYAU9zPzzIC/pxLXbjtLp8eJdZ0v7NWwITjsytc4qQNgDBlR
c1LLbpMhqzeHgTjzWk4XRELNqYRtl7Pt62AwGrF5+gZtfhvQAFu8EyjseOcdx96H
lDVGXDvPf0CgkpxUswoP0aTbz/ohcYjU4Uz2uld1FRByB3Jq6Ptp0yAVoiPUOe7R
rjxzE23FivD+V5kpd0O4XNlm2IEe/VI0KzP5oFN+VjF1E3HynrL6K5oISIvlRaur
asulBxsKOgO2YIgBL8HsBx69lgNE5g9lHGB8DKia3Yn6IbBPp0rZTn4Leja7fn+P
0wdG/GBC1pg=
=lMgc
-END PGP SIGNATURE-


php-8.2.7.tar.xz
SHA256 hash: 4b9fb3dcd7184fe7582d7e44544ec7c5153852a2528de3b6754791258ffbdfa0
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmR/pXsRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzuHw/+IXiF6sgROxqpQCJZRznd+8TJahTudktO
3vsoUqpLGnNOC1uDZt70zE4lrUMYCIlRF9wkUw74IMX6kVqPJTCoPCw44pL7kMg2
lRUC4D5melqlAk1fRLPGqEvwv0DtV7EZTjnGdg4A7XpQwEvdQTxcKtB/SsCcRBrt
BKAf+eiWQYee6P8/9825dxPt6rWjSmwLmhoETnKbB1wJPsNjOSs6LMRl+jRaor/V
CilkoLBN6EPEC9RDjkXKWnPNgscZfe+P6DE8nQhHpaQIWD2Oce463p1XWgveF88r
D0kXt03C+oXR0WYX+igqrglLJE+sHqETZMNbt97f91rvJxyF3+jQ0uYBxPtpusni
0xQjE5MzNEfunhwA6D5MjxhFZR0k20hPHfW/mn4RAxanE7voUntPVZknGOGbhw0Y
4+sG3Xqkg9Qrvv/zH8e8Lmlf2b4xjSHL/ZJ8DLi97mjGxz6UqPPE9rT/CC1ykwXw
ydKNfUCyk8i02bDxf9ru6atw82pGS5oWPh4Ll+sJCHHwh/SIB+d8ZZpbNSHAX+Kx
SD2okLUT4zC/If14VOAby4hqwA/fISFyvgudhNO/8Igq5/G4C9+84UNdGPKmG7SC
UsiXwymwmuFENREmLVe1UD6a7nbcw2xqdR896r86Jtd+od/JPRjDplsLHJvWqS7I
s4OcAY9NILs=
=wc+O
-END PGP SIGNATURE-

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

[PHP-DEV] PHP 8.2.7RC1 available for testing

[Pierrick Charron]

PHP 8.2.7RC1 has just been released and can be downloaded from:

https://downloads.php.net/~pierrick/

or

https://qa.php.net/

or use the git tag: php-8.2.7RC1

Windows binaries are available at: https://windows.php.net/qa/#php-8.2

Please test it carefully, and report any bugs to
https://github.com/php/php-src/issues

PHP 8.2.7 should be expected in 2 weeks, i.e. on June 8th, 2023.

Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/0f99a1daafa21db2d4b2179e56519e29

Thank you, and happy testing!

Regards,
Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.7RC1.tar.bz2
SHA256 hash: 90debac520cbf1eac6e4c6fc25accfcfe3846d37c31cecbe23e948197d34911c
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmRtJpURHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adyyWBAAkjHnKadVo7SU8bxklMOT6j+zNBl6PvS5
ELySa6TBSh62bmKycjEUjK4em4MfioReScISfn+UPQBpLnY2mz3Zd1fUpD8OPucf
EWQZB4Q/T83eyiuinq6cQLbiijlxrGd4l5H0yV6BB3yhDlRhFEXxrZqKodPh/wgA
AmmbQMl/zJpoWqpPfwzBW+MnTwn/yFh76bxSUudpMLW8ayL4os+IUChi3Dpzme29
wQqf2pkwy8tT/o95+rMi4sPy3bBLgs9QaRiNPm43ZANzsKGvoqLM715qtxtXS2MJ
+AdcW7sEYc1mVTGO7S1fj5SNOgYXnn/w3JtG7p7l8WT0K+G78XtD4OJAJ3LJCX3T
H6KdeZ6aNn1Ga7FsFXZy5/2obYOlPKN6axpQKvwQzpybS2l1FXc0ba6YiasoJoMi
vI1ZIX/zvLw04oTe9SAPE8XPQetzVULQ+n+g3TiW8Y2Ff5IjeYAd56emqcniwjdR
U9oprWUITrObulAgnzYkXcf3C2UTnYVIm5qBEdt3GMoZa9HPnAEb00+B8fPoX7rB
qCqVXsF6IJxBFrWQ/5QjpcHfPX5VF+VD4WrqqAkQTwHbwvocuatgXPYeDQmWKN/S
2uCLKWHefItY4LXKpEivBo8RXL3hHdTyxp68hwrie7xBN52gA9gVjSjmwWbXqeiI
8mxNKH+QBmU=
=TaCR
-END PGP SIGNATURE-


php-8.2.7RC1.tar.gz
SHA256 hash: 74a1a69ca1cb1513cef72ad374a68da9f726d1721a0b5f4c5d9c0b437306787e
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmRtJpURHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0ady8QhAAgExY1M+Tq4ppo6HIdWL254R2R5Pc6rYY
aLo8Fa7O61PNSvKaR92Wtx7Jo6VdLmzuAVhhdcK+YpXX2jbdoe4VmRjDWDrRoOvc
cxyZAWEHApo0L9QBTy9VGZyPaRgwQLRIRMud9e14V1NaWxyRkiwRwi6OKjlCCbTb
220rA4ej9LfGOgmhrz7UgBvvzOgIp1275csG6bj64JFVVgsTGX7CvROycYWBa2A7
Pjy9zEpU3JWZpePR7pnRzNGUMjmEfHE4mFQaI08ng2m7RZ4UG9D2BxbXtX8MnVqa
MFWC332N6Nowd06UwDVnTuQYrmEc1voPGM/8WHz4ADf4xzC+yk4kwdS2dVlRVaQ3
1wXqbsn6gYux6Ltl4mfMaz4sqNBDad54AKTn0KUgkd+8y7NbEVhn8P1KdI6zUkem
xRkznEAPkrL3RQR5ADs5o5o5KEkIYZBHHRka/83tOtEI9AFtCINFXGrFLcMWDb7L
LaoxrZG/pwtbyVg5j+Izdv7LbZIi4O8DiPvUBgjyi8bLGi3Pk1NWGkJubUuWlKZl
5nKihu2c+zuR+TV1uTpKT6LTVQvz9xl/tW/C6Ln0YWdKLe+hi3DYutTZHiGo1/rS
B0ZZ/ZrEm1YfztjqqH39ax41cRTWN3RxXxgmmWjgSq9JKKD2ApQnJbq1zudUxipV
WERpFOGtBJM=
=+wH5
-END PGP SIGNATURE-


php-8.2.7RC1.tar.xz
SHA256 hash: af19cc4c5b50034e59186c369fd152c47f86b8eb921b41d67b61e64b42217ce9
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmRtJpYRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwfkA//c6SXBYX1pODR26LyANu2MBy5wmimQeoX
7Gx0ZUKyh/UIWuynE+9GEsQPTlRYYl3zAtROq0toIaR1HVdtuDh/mu9eOzTeJRey
IMHe3insFBb8vFM8nThDzJD/C+mfSZkJAuiwRPSQsOahN9xRxlFbYLMhxZcRQ8cd
Em6z8eSBo/SLrlE1uq89/a34At6jzSI+IbGWIbGnswyBLi+yqBUxmzMZXE/5s4a+
/9AHZv6xdjB9sx5i/uqDcuwyoXnKE8GBNkOEid9SH5vVnXELjSP3122fqzkMfMaV
Kc8Hl787JFWPGtw9lvmMdHOjR8zXen3Mb9enN5mT0c9bG6683Sy3jwdzp9JSQAss
vnlRk+CEcr1JieUnjQRtSL/iLdf85w/lj1uvGA21kasAyAWCGZ7MQ9kLe2mBvzO9
9dsw7NIepqRvhOJJt1YCSbFjASbDfG7I38JBvTnm5NiL6GAobFcZhugld6Sk+tFx
nXMTOkOA8j5mN/MaEnKkLWODOz7gMTUotigfDeRkaMKo7GxIrGpZaG8FEfQC01Wc
i/cc/nV32Akdryna3/cVS3yt9DS6fqKUgS9hcxxrICDa1BjCxcp/WsONwM/dEATk
NhJmiyQedEx2GNLFw/YwTRFXAhPxBfnFF0cpEKFRLN2UTVyBu5aZyEoTiHvzpWYk
WXK5bKnUN3c=
=Pj+q
-END PGP SIGNATURE-

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

Re: [PHP-DEV] [VOTE] PHP 8.3 Release Managers

[Pierrick Charron]

Congratulations !

Eric, Jakub I'll be in touch with you soon.

Pierrick

Le ven. 31 mars 2023, à 18 h 54, Sergey Panteleev  a écrit :

> Hi all,
>
> In the role of "Veteran" release manager, Pierrick Charron [0], the PHP
> 8.2 release manager,
> has volunteered to mentor two rookies, so there will be two seats up for
> grabs.
>
> For those two rookie seats, we’ve got three eager candidates for your
> consideration [1-3].
>
> Voting is now open on https://wiki.php.net/todo/php83 using "Single
> Transferrable Vote" (STV).
> Those who participated in prior elections will recognize the format;
> for the rest, the TL;DR is that it allows each voter to state their
> preference order by voting multiple times.
>
> There are three polls on the wiki for your three preferences, in
> descending order.
>
> Using some math that I’ll leave to Wikipedia[4] to explain,
> we’ll start with the 1st preference and gradually remove candidates with
> the fewest votes,
> transferring votes that had previously gone to them to their voter’s 2nd
> preference, and so on.
> Once two candidates have a quorum (Droop quota), those will be officially
> selected as our RMs.
>
> Derick Rethans has volunteered to proctor the tabulation of the votes,
> since he still has scripts from last year.
>
> As you consider each candidate, please bear in mind that this is a 3.5
> year commitment and is a position of trust.
>
> Thank you in advance for your consideration.
>
> Your 8.2 Release Managers,
> Pierrick Charron, Sergey Panteleev & Ben Ramsey
>
> Vote Opens: 1 April 2023
> Vote Closes: 16 April 2023 12:00:00 UTC
>
> Refs:
> 0 - Pierrick Charron: https://news-web.php.net/php.internals/119668
> 1 - Eric Mann: https://news-web.php.net/php.internals/119647
> 2 - Calvin Buckley: https://news-web.php.net/php.internals/119648
> 3 - Jakub Zelenka: https://news-web.php.net/php.internals/119794
> 4 - https://en.wikipedia.org/wiki/Single_transferable_vote
>

[PHP-DEV] PHP 8.2.5 Released!

[Pierrick Charron]

The PHP development team announces the immediate availability of PHP
8.2.5. This is a bugfix release.

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

For source downloads of PHP 8.2.5 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_5.php>
Downloads:<https://php.net/downloads>
Windows downloads:<https://windows.php.net/download#php-8.2>
Changelog:<https://php.net/ChangeLog-8.php#8.2.5>
Release Manifest: <
https://gist.github.com/adoy/ff01bd80fa225d35757b8077fe9af2c3>

Many thanks to all the contributors and supporters!

Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.5.tar.bz2
SHA256 hash:
e5a80663cca4f6044ad86a489798147c7af037eca96f6cd357ab36d28cb63757
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmQ1iHgRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwXaQ//dTXhx/Ya9UF+bczjw6FOY0QAocZi0Ibj
50Dtg5ooCpIpNZabYsvqAP0V5vQ6Kz+evg37dM4l2A3yKKPOw38M2XvUudkx/kIx
n2glwvFN9xjaZmsmtMN08Cm3aotGP4tzhemNZPQS3FFUHCp4ao/VGgv5NokAseaL
p/LD/BX9kN12xwDkd7apss4xF9kEiuhF2uNZbCZdkL6xlugATDYE8bxjEounJled
wliHkYAbzaj7yugiSfK/ex9Ptbd+Xr9nL6AHibFCixKS3nzQqoEuroDLmfH0gsz7
Gm3GBeuamFZv+tvTAXQ3wtGD4+MotopwhT9tKJmqrZZ+LyOhV982qB34LkMYnByf
bU227/gqm/N0qU5m4RxCfkpEDsI+3acEmHPWON3e7gbwwdbHQ3vmqf2wtqNEUwhI
Log1AKRsZfZETHpstEGj9rqHP6ys2xKCrTPrKkrC3wuAUCXB71y5epQk4aFO4e6/
Hwmg3X1UqJ9suAhi65mkqJ7sxkusSMdWJ47x4SA0OCFfRJcc7+9pxGO/WDmLpsVN
9fuV5z6q2hs4QXgk9mmkg3IIl5c0sFuKM5V8CVBoEpJrupq0amHL8IRxpUsQu3tn
MsHXSkvBdT297MJzH+rhgwCrQdPgC7S+gVakJViXbl6MguqXA5P9xrjG5VxUZBqz
K60J9XlhHko=
=7LAi
-END PGP SIGNATURE-


php-8.2.5.tar.gz
SHA256 hash:
8974dea2507155471660b13a0bcbdc165ac778eeb845a7dbd65d5ffb92738c0a
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmQ1iHkRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwAwA//UKPyqWdnXPHmUMoz1wZhAPIUa7O1lje5
1xcYXztCMYO43nomsVNnRAmeZV7hVed7udVXaiKHfJarDDsNS6+z2yGwTtKfbX9A
FLVwZ05mLy5/9q/URyyPW7WpzscHQp2vBw9UCFmiL2ICNShoKTSVIAM8Q93MlX2o
KB/e+RBrbO6Wy0WxhuuL1LfhQQUhQzhTP9fXNVqL56oJr4hOCk+G0nEvQJK+0w5K
KjbgWnahKJk76YzYQUGlmsGyA/bLLjeC+z+/s382mmAoNL+cw8UNnR4C/uFhRU0B
ofHBAsK4s9zh0pu9qz6yAy3GTxBPfWo41NsGSBy10LSNjqBnZCDZndJebYGWrQUU
lIez3cVhDM8VfPXEdPzLNN2GwedBECb2R9e0oQcMn8afFgPiW3t0CsKpkKQbK74M
BOxBMV7W3JQHH+0lA5VAKVCVsGEZIx2Pm7Rr4H7Xs6rG4dlbszhkQUsb0Zlq2qxo
D05fXx7W9VIGCJ4ACkyHVOi7sx7HQ+YwJJnioxtg9eKHrmeQ5/j6JtPH7d1lEAT2
1L5MZ2cFxPYMm0gK1RKevuYj2veLGemodCs8ZPRnWqKzGtFEXtsiTxldNkydXRKU
z4xmiWyfpIj9YTgMdToVT5ZNg/b829okTiMzd5KheN7ORTusAbxS1lvyb//h8fDL
l2XAM9s4HzM=
=Mmmn
-END PGP SIGNATURE-


php-8.2.5.tar.xz
SHA256 hash:
800738c359b7f1e67e40c22713d2d90276bc85ba1c21b43d99edd43c254c5f76
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmQ1iHkRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0ady/BA/1F2tRthnhSTnXcWr9t/kn2KJEATHWRxV+
l89z5Whln9mgSE0aaljQ1p0cH0WviD5y6/xuhnHeTVHcSHCTG+yGwormKSxDfQ1s
FIbWJw9QCfs8nSApqZxcddiraxK57emMbXDwwKx36Is6Oh80A70NJ7xxZJbZJq2Q
iojQ/QwPzgFebgfAJGjXK1GneMSF0fDMU9wppijhmMBjN/XSImBQPd9M6Cbujvyv
a3n8XgG/kfBnRimR51jgW50PodVy90X2/F4AJOABsiuGtLKnU5hNpRFs43KuR/4H
V99kODHp8o2O/OHz/rIaoUevzK4QklEI4F5sSg0EeltvzKL3N/jxpXHciGNELULV
LRQh8ZYzSicfOL3fFduw+3oqXZPDD0g2bsCCduiHSvldj+7/106+Dy6+Cs/s1jwN
1PkmVZ81ALXxOrl085+NIZTfymvlI8PIPAhgaAHs7f5f6OOS+IuW6Cx5dA0gLimb
vNU4Nc+AAs82bBm/wTyqB1uWiA6wG8I5keO7osTJbeHZYl95lGpZrwik7l2AxTBk
S6cHgI5+wrBtyHBQd0Z9wTCMKSZZfEpN9gkH+J1YrLndHzumlbIpNgjm9dtItf4k
D+NS9NWeawKsLknff17uVsk6HuC2IVtcYUvRFXzsSntc5jR8Uy50MWroI7LXI8gt
58G7sC8IjQ==
=BZ2g
-END PGP SIGNATURE-

[PHP-DEV] PHP 8.2.5RC1 available for testing

[Pierrick Charron]

PHP 8.2.5RC1 has just been released and can be downloaded from:

https://downloads.php.net/~pierrick/

or

https://qa.php.net/

or use the git tag: php-8.2.5RC1

Windows binaries are available at: https://windows.php.net/qa/#php-8.2

Please test it carefully, and report any bugs to
https://github.com/php/php-src/issues

PHP 8.2.5 should be expected in 2 weeks, i.e. on April 13th, 2023.

Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/605566c637bf18d7e817e1061a0c0602

Thank you, and happy testing!

Regards,
Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.5RC1.tar.bz2
SHA256 hash:
bf23c472e87760b05daab565e6b1a1f40bbcd1e9d1bce9414c5b938bb5ba90f2
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmQjXbcRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0ady7BA//R+hHMKueR18dWrEa8ybt7DjiLT4AcSxV
5bIJvzBXZCjzFgB6XMi4QuSm1rpbsJBgvzFd2vFpGlATC+och+9bnQVz8dbkQf3U
GN0yBBHEuSj1IZn6Nc50l8Yg1F0lEI2jEgqrGWWkltvVw0ZODrkRNaK+s19nc2No
JGa82zYSjJsfqocRybe/7ctnjYJapYDW2EG7C0xGPuakF3B8NuaaPxwJ3rvTMQhS
FGyKNhGxNkqbabiLn87Qg8jiw9xu6ytTm3tSN3t1NyPWyT9B0becE9LCAzYt5YSv
zK0zwaWY6evgY+m5nxQkUGayNnTrwjtt+W6r4UdX5rFDlaXkpJR+1zHTF03WRo5m
Jg36EHozFzSIY3XUp7kzrneWlTJoJleydQ2quQwAv/p5pSr3Y4NR1tj20tfUIVZ5
212B4NwQ3RhBptGkDBE/YRlVtUxbmrUKbVwaSPJfAxkUcnNPlcypVlQwkqwtyrqx
DFOAwdupU6u9jPyevuyJrueizYanp5hV7CgYys9nxAi/ZG4VR/qJpAwUI8BiZAVg
PIPj8EQUdVfVhQIS76dl+7ksAEC/H0tm08SUNhI34Z2gHXLvR8HEbxv9qmi22j43
2rRKKCGwH6o538jjUoK9kTLK2lBBPZ3LIzYm2QsJTUwMWt2Q1BXkKjTmBGR8zgwt
w1AWph7ET5o=
=MGa5
-END PGP SIGNATURE-


php-8.2.5RC1.tar.gz
SHA256 hash:
f282407a71036e0619c7eadb0a42955ff70cee1133abeb472aad450d6e9911bb
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmQjXbcRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzXww/+Lw8oamj4hBTBffn11jFVGaQJUeYE8jGk
mU8xIq6AVoW+8Wo2kfK8CMR5W3DzV2xq6F5yx8wFso+W8RubOU4DUpXttCiNnPMr
PzzNLdwQmVOhbrrvRciEMKFYGVPHBWqNtM7B11uBLkeW4GhPbqajRQofR+y3tCSu
AajuogKkOAMyODxQ2gPfv/8tz5ev2p2TmjyvJ9WkX99navcp/IUIglQtR+sDFk9X
Q7eyJ2g2ektNDKC51ucgPHYCVg0+fyJw6Ay0UEY+cLgp8FtrVubwnduZND8tAnU/
h1jdfY2HrHz5Kt05TnMlBR/nCct6zCXoOdpLM+27Wzf/x4NdEX02vZ5qZG6Tg6EO
FM5NiwVAJ9BNuvcr/7y4E9yri3KgfVzWyX3XIx8XoV4lpVcOqOFLKp5ENgnztnhS
NCwAgMBgJ9IYsXdtaf6ouIUZwhOBk9vnUhiKmYGM1/ppsb54spZCnsIJegw12bvf
jWegPKa2t7Wii640lqs7OXePzmDmhQOudalzoStxkBupflAicZxwhyWMtzpVBQLO
Mig/51Eoy8oQSz5yec7phjFOY3/9xAagdCBCm/eyeYvZ3a8TE41KszF1fJSoKHEo
1bswG408uRUjcSdNZl2dNavOOCC//pWLYThztoA31spszOFqhrPZ75eE5Ap9NbLx
UOZDFf28cn0=
=MRNw
-END PGP SIGNATURE-


php-8.2.5RC1.tar.xz
SHA256 hash:
2f0fca5f7e718fdc41aa43117473e6e973fd46ee49572ef5491f66848ceb2e88
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmQjXbgRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0ady+3hAAtImi3zaqvNBpNeC3B0JsKsJLnFVRs/RP
qtljne4iG11L/ML3/n/vTQakQK/WR+zoXKIsHiPL0rM5Tut9TUvBltqgbN6VjCeq
CpDuXfQfTXCIOT2iQbWFyp9yfO3HTvOipRRNJx9Z3MWDJt/qVydnTbWE2BldgD62
1IetskEPJKeXuSdWUpjThNG2ECkOfSl88hWYgnPQlUA4TGeOm2ddHHb28MCTGbga
SIOsqBRRj7JyaiFLZrkllbBnoI1yzJcG+v3y4RC6WYS2ljFX3h259Y5oTiR56Oxr
rJG57bqAOUQhpMC7qOAuh0wzBYA0JuoYP0sBQy35J6U2dFfD2OyYlInowRmLfini
MQdvPnHVDNiVdob67586xV9n9cygvecuAdojVk8yGprBN+UP1V4JcbwVuzNiQ4GI
D1wpfSY2cnd6FwSzffS7O99HRT0l7j1N0yGsrpxRAtp6/SIzBiLZsnk/02p/v4ut
yxsf3fsYs/HnRbu/dhvaVIAGzImSZcNktjm9UT0uHuzxu8NPjUSYn3VUAESG6Hlg
a+1OAHriZAwWmDVwDGwuzIdbhlU39LoEvw3R0NlJLVb81VZxwBqmSRa1Ev87MsDQ
w4alNcf/14rLm4byWOZ3mUnKE2ukGyxrKm6gmcy4vqojPMZlnRkmR74bcCirPwIb
dkCHoj2TXxI=
=kACq
-END PGP SIGNATURE-

Re: [PHP-DEV] Release Managers for PHP 8.3

[Pierrick Charron]

Hi everyone,

I want to let you know that I'm interested in volunteering as the veteran
release manager for PHP 8.3. I would be honored to help the two new release
managers who will be joining the team, and strive to provide the same level
of support that Ben did for Sergey and me.

Cheers,
Pierrick

Le mer. 1 mars 2023, à 15 h 21, Sergey Panteleev  a écrit :

> Hi all,
>
> It's time to start the process of finding and electing RMs for the next
> minor PHP release.
>
> We are looking for three souls to take on this role. Whomsoever is elected
> will be guided and helped by the current, as well as previous RMs and the
> excellent documentation in release-process.md [1].
>
> Candidates should have a reasonable knowledge of internals (without
> necessarily being a C guru), be confident about merging pull requests
> without breaking backward compatibility, doing triage for bugs, liaising
> with previous release managers, and generally getting the branch in good
> shape, as these are among the activities you will be undertaking as release
> manager.
>
> Notably, at least one of the volunteers must be a "veteran" release
> manager, meaning they have participated in at least one release of PHP in
> the past. The other may be an additional veteran, or more ideally, someone
> new to the RM role (in order to increase our supply of veteran RMs).
>
> Please put your name forward here if you wish to be considered a
> candidate. An initial TODO page has been added to the wiki and contains
> provisional dates for GA and pre-releases [2].
>
> [1] https://github.com/php/php-src/blob/master/docs/release-process.md
> [2] https://wiki.php.net/todo/php83
>
> Let's all make PHP awesome!
> Pierrick Charron, Sergey Panteleev & Ben Ramsey
>

[PHP-DEV] PHP 8.2.3 Released!

[Pierrick Charron]

The PHP development team announces the immediate availability of PHP
8.2.3. This is a security release that addresses CVE-2023-0567,
CVE-2023-0568, and CVE-2023-0662.

All PHP 8.2 users are advised to upgrade to this version.

For source downloads of PHP 8.2.3 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_3.php>
Downloads:<https://php.net/downloads>
Windows downloads:<https://windows.php.net/download#php-8.2>
Changelog:<https://php.net/ChangeLog-8.php#8.2.3>
Release Manifest:
<https://gist.github.com/adoy/84a1d24d540ab7bf637370bcb1c56063>

Many thanks to all the contributors and supporters!

Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.3.tar.bz2
SHA256 hash:
87bb58865f38f5e2941813029152cea2102fe2961bb4d68b88f831ddd0548d0f
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmPq34URHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzDHBAAkcY8DrNEQ23h7Bhzg5l7tiLC/an4FFKP
16hndcjdhlARuZ5+ndh5JbJ9rmb+0Hu9aFK8A2irhzrtpm3nR21KWaAiKjUdiMqg
9RLoJrK+fsZGshloGTLtFHyj2KFZmQ3ey5XeQb7du4Ff2gkGj/kTXUnZRloX/53d
69+4fnfbX8qQ54+NtNMhWWwB2zeMSQldhQrzgXIiyf3XVocEo254m3eF45yjGq6/
FrtpgfCg+7bj9sKDArvNMvlZq1OTOWfytMWdNjNFmNLAVSoCy0r0X95E7CKqCb4F
2gAJ6fvNf1CWGz5B40QOpGGTVRE3oqFh2Z89g3/iTBIb6VNRWKLFHIm7EelcMY2s
hTY8fQgJMaIa2Ns6h9qk+AtF3fo+/7TfiLU8dvFpedBNNVTeg7OF3fFTPu1Stbx2
9uFetGQt/5f+Y5Qf5WgXMIaaZ1XDCCZ+qGKv0ZZSRcUe5DlI4VjZ14UcYT3hpcV1
pU2wxjbdzMpAKz/VIRfCX2h0dOBU2vEKfRUzKmU/x7YXnMIWHUjlj0coUldR1aot
gtIzyVho0MIrZpP6mo5uZHGGs6q5gvljwSUYUtB4w5bh2cslVDclenZHu3PwLxUx
HR15ncya4PZYa/eHa1jHyj3G27Pyed4U0CDBSrDIiXk5NL36K3Dd6kiKAsWWx8/C
2dE9LQnfsog=
=vppH
-END PGP SIGNATURE-


php-8.2.3.tar.gz
SHA256 hash:
7c475bcbe61d28b6878604b1b6f387f39d1a63b5f21fa8156fd7aa615d43e259
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmPq34YRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adw8ew//ek30lufYe1GOikaxzECTUjPJiDimr/0S
Ur1lDE5BLORbIUQjgN8ohhtWlKCj1ByoR/0dvcJxf2o5Ru8sEWa9Dmq/FFwvsce2
Gzl5dtq4iaMLYr5elKP0/avcuEnTVEu7o4cBG380ER95eF7tLh5jVpexqOF0bDhN
EJgcbcD+L0sOO/mA4zM0gw0JGbUYfSP0d0/M3/sgr2CVnlkqiZEmZkDojYUQ9btR
N8tNUKMoKMlkOl4yw1PjxdeKPV6BnUKoAIW9I7FazMUuqW3bTUsLK9s2d/I1L+ev
4WsFnL1IG4l5XZmtfs7xuukRbJTrjxjUEkyR72byMika4CgjBc/qDLVFTPuLkJMO
upWOXD9kWDwtA0qIyhLmO2S5RsSq4q2N+QerzKaRFKXHwcr4BibDPh+DhVMDA4oF
/s277UMBhasWAEoFh8nNbneup9mISt6r12qbimHF5Pam9tQDR5lar2qYC52gLFGl
bm7uNE2xV3vVN/47BYmWzgF3FQrqdoiB5ddGTXKao7HBJPbalARs1JnyyB7MgYpP
pgaI++5Qco6QWS5iXgN9NTJE8J59+9o+toS6kue0z/SLOfnUV3cyWa/kzpQRVzMs
tunuCyVHjqsvF5/Q8H2m5nSidOFIouvN9ISJNWDEFBFZ695ZlruyihneuIaSXjn+
WkK8YTteaeY=
=iM3G
-END PGP SIGNATURE-


php-8.2.3.tar.xz
SHA256 hash:
b9b566686e351125d67568a33291650eb8dfa26614d205d70d82e6e92613d457
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmPq34YRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwq9Q/+Pseb8DVQRejcfOWjIrkT3UqofoNcxVpH
2Qhc1nQ8WJY8pwoTxBzspzxujY7SkZ7Fqjt0YihI+YpER+zEIuZe0atVUgamLJw7
AFlM0Rbh4peEVSPsGdVGZR/uOhQrxmoG8T1gGFcbIIXRiwvhb1pDPp+EZj+liYds
V8WlM5ln5MKWS7S2VJrnP6x49xzRGOnmyVjsv/Ln1bprdsRdneDzrwoWYWpK6pXz
ACg3CCEhQAxQJgvCNeLCFUckf+uzF1AAjJ2tGUdGZYQLUPWJ5lhx6sf8nF++hYzS
PyC/18ASR8HvVw/tHlbkusH/7FM9Z20/tGf7V5RlF1TSMPNtlGQ6MLUf7/yIlfcX
u7tfIUv4DPH++AtcrWLN+3pyi49EyCqUd0U4qxQ2JW0jzLaOQHiE5Sd4dkEGfuPx
5rffWExLpU/S5MXmQG4JJdVM5J+OkaYG1A1+FtaQ2yym3j2vTtu68r4QdgMMsK7Z
mSjb9V/QiTvv4BSQK6YYsd8xpGqY/PijV4+XcUjP3JEIuiD+BUwFA7IPCn8972b/
fdXpXOXBqpKaO929gBFfvU7+77FwQc0nmgDhOtkvQOs2eSq9+AhhkVPPZYGjkvra
D4Zm1p2UpwsUq5uxPmREC0HqgUWsL7W0kfMZjL6cIw/UOpL1z63HhyMCIk4sBcQT
X2QsVEDMOxg=
=QDlZ
-END PGP SIGNATURE-

[PHP-DEV] PHP 8.2.1 Released!

[Pierrick Charron]

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

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

For source downloads of PHP 8.2.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: <https://php.net/releases/8_2_1.php>
Downloads:<https://php.net/downloads>
Windows downloads:<https://windows.php.net/download#php-8.2>
Changelog:<https://php.net/ChangeLog-8.php#8.2.1>
Release Manifest:
<https://gist.github.com/adoy/c6aaeec96698f6005419df666eef054f>

Many thanks to all the contributors and supporters!

Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.1.tar.bz2
SHA256 hash:
75d6f8f365993ec0d1d9c6281d4557e6feec5a26194a468b8b01459d177efb29
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmO0fXIRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwQQhAAiqj59V2MQwvCNeFd216zMCLLbDIp9ruh
9wOmsgxZT1OXCUl3FPCpv9zkLsiQuoOlCIS5SCyHUnDiSh/XK0l7pzsOVIjW2q83
pkmvgapW3zMGT5WpMout83QCwmY0/tZ+8uoBtm2YNbVZkzce1s48if2ijAVnM0zu
T/ThUqKe8H+4p84+ry/1DAYrJw+iUuadaV2JRXkMiyxVXsyysSsK5brjKnl6Kw55
phnrZDSTmEIbYd5x4P+57A3KsNywagIGgiJJ5+5VpSNz6vWouqR0pPYbDTlrn8+K
AHW/s5CluRn1t6yqeYPdAAKVGn2XIzxZfikLkgp/EXG84aTgJKIXWhxUmrcuQ7g7
Nz9mQz4mISnhtRJtDUeaOlIQ5CVHdG/KjOjeSDwYbNE3ZgWwcAXlFWyV2prGDn+D
z3HRX1FRJeZTeaavS2xcmush3tee4lrHIg7/2Mbe1RjDVVH1jyij2pXhSJjrGErq
izkui7SxEr88o8XTKb7HDk5lMkzyp4V76qHza5LQNfT6bQu1zce5bEXjzSFFAVIB
3bS2WE2Lt60IpVn2rpitXt+fUQymlqKucOUaMecqcx5T5+cv0ZOJx47YhDETeWRF
q490sPvpnYrFSASWGePpHtO2FPcs3ItQw7z6jDWOHULx/kdKc5OQFAhLSW/PU8Mh
ne8PnJhivEc=
=rryu
-END PGP SIGNATURE-


php-8.2.1.tar.gz
SHA256 hash:
6d7b1b8feb14fd1c65a2bc9d0f72c75589a61a946566cf9c3bf9536a5530b635
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmO0fXgRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzOTw//Rur0GvrTMZoB/higRWtXALw9m0qh+pow
FgPrFGP3Sk0xV9ZsaigI/HLwhAhC95OjeKAkqfd/+F6sZrk9U5vxK5UWXhfYsLRE
TGbkgbC+F2otVsmkJ0YhP2T4qUK3RtcX5h5eYSE+KxWmkMZ1Ww2oDJoEIRW7KeQh
+qMie2POHJV2Az0A7bjgs0xL/z1PNdQc0L5VhZWtesnjiQHbiuM36glDdd8s6KrL
UiGewEZx0t5j08783Zo2i15n2vTYArxtnP3Jx1c8Yidbs6l+AgxFqmlKE71xJlty
vWd8v1Q+R75enWo1R4pALxrj8eMlwas+ilxxpt3NuXbNWi2lGQGjU2jBT2qx4lzN
J+YuCu1Uw2F8vKzODi/DLwjc5HDZIy97sLTW7ocEr324ouLMES2DOmRahii/8Wv/
qqVeKDM20be8toSIFoDwDw4hmPbAltrK7/5w5CwauFbBDTMmhIBfO5aDzcHZrAig
M5l9uILf9NWBmFZhNgGkzj/qImxMaY2j47XpiCyFKiFxdhBZaq9hCCclj/sq0l+3
DFD2aGbgzr0oT/qd3MvIBdyTd0ktWa6dN8XZoqLvjrfIG9GZb3vJ58uAyeKSKkZE
CQKkYmKAYkbNtbe18cq6hxtCRPJnNtTh8shG7NOggj1VBQkl3Z+L8x/jYewwtZLA
OoBscHpz8yc=
=2PzF
-END PGP SIGNATURE-


php-8.2.1.tar.xz
SHA256 hash:
650d3bd7a056cabf07f6a0f6f1dd8ba45cd369574bbeaa36de7d1ece212c17af
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmO0fXgRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0ady+SBAAppV+tD0iYBCxR+7meZiQj+VLhb824vOq
GbwlUi8nE1i1dzxNLQFcCyXJK4R2hm1/Xw24hhXdAsUixEcwMaY6UvFlm2iLMedD
vZhZ/u3X4AV4s9DWdOKOk9AtXBJMXd5oVEkMgOkFJae27eEnYMDSQ+OMTPn7qpk9
o4ch/8fxW6A7RiQuhN5VglFZLLtESnzdNyL/M9W3/NwLlaZxb1mHBJ+cIOrQU0du
CjArRyurMYPNocEX7na+6PqLeMnew45cmESAj+atRfJgiuJ7y/vGb56xfcS7XVP1
z0JPJ/UsCmr4ex+EKbs1iLrgxBYkNQhf3FwbI0/UaYK+2WcznZM5eqcWlVYPnq52
iBvm96/d8sapTk6Ydcb0CdXr3Wwz/txQjERIHB+TJRNSmB9qUpK7VVYeXKJ/jazB
scMTOjBxEexJgY3MujPXZxaIolmd9lm71m9xbh2xvPP5aPjQUudHfoHIpdmPe5Jk
ACLV/+UD2mFMdVfa+w5cLkVMaaZk8h7rvvrESUq0rbuESuABhWMGU/+37NOM/JpD
fY4+qcltbqHgcE2dNGqwdIcHeaVej6hxmkdt7bUJ7FGULRwmn0cy5/hebDvqGjG8
HSjLFe4WLqvfjHUe4wgMjZgSiA6TMuJ8BD7MnCDmbeMNSROOCOeyxe6trOCADVTD
l+HxVWxKc+E=
=qIiW
-END PGP SIGNATURE-

[PHP-DEV] PHP 8.2.1RC1 available for testing

[Pierrick Charron]

PHP 8.2.1RC1 has just been released and can be downloaded from:

https://downloads.php.net/~pierrick/

or

https://qa.php.net/

or use the git tag: php-8.2.1RC1

Windows binaries are available at: https://windows.php.net/qa/#php-8.2

Please test it carefully, and report any bugs to
https://github.com/php/php-src/issues

PHP 8.2.1 should be expected in 3 weeks, i.e. on January 5th, 2023.

Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/c36f55df35419d33a19b35b2f11d16db

Thank you, happy testing and happy end of the year !

Regards,
Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.1RC1.tar.bz2
SHA256 hash:
2bd8d594fdaad246c9269d6e215850886f7abc44b00b8a20f28524ba61cf3b71
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmOZGg0RHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adw22Q//QsjxUSMeCfENhbpQJcD8MhfAoS4eXmaG
A+P0b/RDi22n6uo6Gi/AVC+80vTHiZcahM/WqyZvSTFjQ3mgssD2lMQx/Ga25NlU
5+fgMWAluSqf8F279qlknl/46dvQGx2+smVsJtjNbvJjHG1VphIA8Zrto4hgvoSH
AqMB/YyX9z5fYDYzJBIwvzokVqM7B7b/FIT9lDjphEAiK/ZOMVLEuzey+4EQM8q7
lI6CXnK2z6EcIgHSk6vfeT2ZuujVLzH6xE1SP9B200BKHY9hFoSvcwB94bxnKw7b
IKEHibnQjJbZlGb3t7wcu4A/RCdIyvuwmbM15YhMT7aHQhS0XjiI26UmCozRMgU2
HgQ9bVLIyqO9VEHmnTwrNkOWnVi1Ysf/xbEnSWe2XyL76WbZso/l5UcZu3cgm1ej
e0UeqA7nZ9siP6io+JSvbXqQeYzC3QYzVoNUN3euinmQeVI1so6kWR2qcgV78UPz
XfzdmeUry6R+Q3c22O6DhDRQwLKmcw7WlbhvgsnsuzQcOM6eveR5/DdawJL5OnTI
kyoC8+cAJlmailRlarpo+GjF99BxSbQPxhd0zn024EknmCfyB3Ukbz4+bshY+WHL
1kK+HVD7QuCEm7JMNOv/tfr0uA88Fgf8IR+Sfl9J/WrIcXO6/V0E3y2LpyUeAjo+
KusAHEzdohk=
=37X4
-END PGP SIGNATURE-


php-8.2.1RC1.tar.gz
SHA256 hash:
3e6e9964cac04618db84905a0b984e03a7bb7327fdf18f87c884a86495643adb
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmOZGg4RHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzlkQ/+NY2nd/oqjaQ8gC7HsbsHTcumONRlMhSf
ZecuNZ4/Y+TfhpdjjrUV+OXifb4d+KXRNMo/WB3wgPmsb4lYnTrbKh4Fcj/FOPwY
8e72sOQ+LdB9UzxQj+CiTcb1IKl9e/NRHXiOJ9gnyVNlCjJHfQYlbx8Qrzhcbq8k
SY9/KnZH/YPGW26XoemrMPPFKVDFo3LJXpLUVdCQbr38GFoFAbBla9ifZRDg+UKX
li9LxE+N9L4Z/WgdCIHVgNbAVHBIX/NMH1y+lm/kJ/6cfM3yA8PaXggkWS9eT6qW
kACHxBAosGVfLF7OsT8JE5RphuwFEv3WAX0I17DtKKVBKfDhfXJwFdAFgLE8Txel
6xseZ3SmdaT7E6cctGsZh/Md6JgoJJH0doIQBgcY8RMygyOrrgisy/QEDIerUb5X
6KCfAhjT9XisNhz5mwBtjWDOtgmvQcnly027Ld4lojnygg9SoBxZNuWHyPRi3kj+
UBW+hfgPzOv2cL3Xvd07wtt/jrEd+Dfd0IZ0OMbFRV/GjtI84NeQ+Vhq076npoTs
J9Dv0IUGrIaGzidtsagkbJbKTrqlxVZ92JKtPOapQO0VV4qDaqCkGVd00HK1IEtm
GIy1yQ0SCC6jlFP7cuV6fk3yp+yiPrjMBk9Q+rol3J6aNOSo+cd9N5US/UHx9CgL
vQBRqoEWLBw=
=Yzfc
-END PGP SIGNATURE-


php-8.2.1RC1.tar.xz
SHA256 hash:
21197edda0c3a8dcc9f9df708bb8dabf9fed10de4dd05d407f44abf43bb0fedf
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmOZGg4RHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwY5g//W4xOwp7iEBFkITniwclOQ7ezeBOcPfqz
9alUpgLj4MdxfpsXwdAyBk+EGYRrgP0dsWcFOtaKCcSX/wR/zBXLxk2bScJHaXTw
gSAc23DytvYaZth1NeVtDrpar+DROq86dPSSOxTAX5KxilSwrnjRUv2Usq9isF5E
HOmbVZzMSoDvA1N+iLBLbwKj075HwK7bFcHYQ/s/afygQPwyDkb0YcLd+V01kzGS
Hsv6y1r2hLFtEQSWTNYCSYYZZ0hSqh9NElFhRLFoOvhBB5WK6GrIpF3ekvZeobjz
aU5i/rPUFIvwfZ3s75sejlWRoJI1/KgMCF8c7leF7cGZ/rL0QeIHzUKduLm0zDrs
AlXj5quCodOpp9JB4Fc/CFNWTZkIftgu9w09IETZXZQ/0/oPLq+vh+yecxdhUeD3
MhskrFvKs1AjpCccE6wgVf7AruCriQJrf3i0lHIVMbNfN53Ahw6kUATvaWNMMqow
0QyJ4/sMo6rLvCsURYiQAR6j1PFplvA5GUMPFqcTstcEKEMFPDxelvo8hbVxxewa
77OdGpSHVS5VUYA5PafQqPO01ucM2cRAh1Gp+ww3fEtj7hKFV3rTK5z6WSSWW/KB
lzs4Zq5sYbbtwtDBArIYYVJUaFrYry4rXrIONGKi80qMfQ+iOKIKFNNGB4JDE5/3
/9Nyt6vR/NI=
=RoFl
-END PGP SIGNATURE-

[PHP-DEV] PHP 8.2.0RC7 available for testing

[Pierrick Charron]

PHP 8.2.0RC7 has just been released and can be downloaded from:

https://downloads.php.net/~pierrick

or

https://qa.php.net/

or use the git tag: php-8.2.0RC7

Windows binaries are available at: https://windows.php.net/qa/#php-8.2

Please test it carefully, and report any bugs to
https://github.com/php/php-src/issues

The production-ready, general availability release, PHP 8.2.0, should
be expected in 2 weeks, i.e., on 8 Dec 2022.

Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/4d1230e5a9afceb95f1fd028b05d1a07

Thank you, and happy testing!

Regards,
Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.0RC7.tar.bz2
SHA256 hash:
dedd83919b6483399ef5896ff2f08f1f0e8e599ab4ff6d4c4ad1c6c711c8fdbd
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmN9ED8RHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwTuw//bazD4MBFKojv4OGcWw6nSA3sNqsYT62R
K9O11+c2DgGsEXXpc6eO8/x/3v+2Z12RhI3GbKPG/CcQlCK0FW65uEQsbR5uLBx9
AhYHcXOZ5s/YJn5e41sIdvmazsoWWgSO8hZcQ8OQ2XcLnOD3t76EYit8WzEY+HCE
K8SQBCXgKNjKlDF5N+LFFy63dGiGofWF2E1NLvn9U1MZweyBypoydfLLCUJsPncm
qBGbIco15oe6Br2vWNa2+3q6fOTI7RJAWgoEU92aN/AllPsz+Ca98XnHk3U6VFVj
bdGENJj6FJfRL5fcPgS9vIGwtYCE+yfqKWD1D0sac5KQS8/9b64S3x+zLkt02z7K
cTyu8kUa4dLLpo1j2GOPf64hRZNhLDITaCroGzPU5Zvnvgl6ej6HR7G86U5GRWgq
M5i6vfZC4wy0W2WtKCZOHguz6qtpxSG2HyjOJJ227dhBPQhKiCaalKnCOPhnASxv
6L86MvaaKrfvX0zH7e5fGwWBrq28hloOyNqQrHylu1GVruePs48ZSir8utfcqwH3
cEI2JjT+NuiPVL3HMequri2I8TyjBInu2i3pidZXMip8e2e8jt/FAexewuYYAp6Y
HwlO4CIt1L8+naGVWf3siNI0aUgyGcmUezm1sfW8hDoXKnsdIG0d3MoWVOPkDGjc
bg61lNMkDkw=
=goTl
-END PGP SIGNATURE-


php-8.2.0RC7.tar.gz
SHA256 hash:
2d123b64bdff600e142bc93fea9fcc7248878fd4c3ca9f376d06d14dab19613b
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmN9EEARHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwSSBAApFLufKdp8hveP1TeUS6nPLB8Uol5JFk7
gGpDmTKezCmK90olzllDX0ZNhFwt6ZA6q09XL9dmzg6ApEb5BajQ5oDVOzvqNdmM
BviV6XGCaotwClq3K3gtTsLJM1oZALW1BYVzqKaYogwMYU4OB8OwxND6eg65aYVA
6lrKCdCFJ0lPNXTZpKS7abbBp9ghvoAARpTYBfd9Edyq+o6pjWcWR2LfSp3P7ftV
Zu8YkM9pZJNMExzoQYo7sUqwhieleNPN9gcu6WXJS340pL8PA7fmFyfQJZzjhTzB
Dv52L1JuXg3ILzNd1UNMSYjbx00bPLxnhkZ5v6MpZ2h00RTwl0KfoiAhf6W85f7o
f9BSw7APzJyBuIdifCMw+yF4OVh76Nh9fZGRfwcOMCH24ecEBiwZY7M1QwBQO0CS
BhEgBtHmpGqZZwsobnn8jSZ71J1qo1Qr48xcb66pTHs2BpB9mBk7lqJinnTSUz+A
JV3MXzwWph9yGxx+YUruf+GvgHgDkNnRCjaLXT/8/4DHfDGTQxAnMWIvuJ2pW1NO
daRVDXaSdbfCes5CHr8oHMK30IzzzR+s91DBsgkhaPHxHlRpmJ2R3fs0ZA1Bi9nB
RYUWv0e+YaBedWbunn+JR+3ADFjzA0s6z2Gru6F6SvgcFHffJ/pv49WHocyInjtR
QK4cXfJiU9g=
=LxsN
-END PGP SIGNATURE-


php-8.2.0RC7.tar.xz
SHA256 hash:
31204434c525f85e64f666a766f623443637616b184e8652414f619a127c5ef7
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmN9EEARHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adyAQA/9EDq3rL/XDRITkmfyd1SL206bMAdKBOUt
ZUei+cdbvMVdmibLQf78uTKXsCLMy+WEpHsbL4h6imH2YOIRc5HFmHg2Zu/PZNz0
EWTUCVj63SrpCVf3tneKlTJCvGe9pDulNPNwroz/l18NY7T+f1xbHCab+nOHKlJ+
c08GNUjgyIF4XJWUnCu+eI/5KLq1Xy+Z7J4TH7py3s9wN/eyWjb+nBnGp0CXlVg1
8CbWn217JIaNWM3XRjc3L/GOP/cxc5kiwhyv2hB3IRwX8mawxb+UrlM4fEt+J20l
oM7wqOl5Jl4QmhELwC+4kWYoV83p0KSN2ExMxyuAhmgIHY1nS/OOKih7tWMzeIxw
I5nXioUiqCNzZjDiL9E+jF65aO3oJbw7Qv0MG6ejYPTvYG07kZX9z21T6Dlnuqrr
iz7hsSN0DI5gQ40nFY314TqSMxjHnUbXHGZTwU7rbA447wkjOASqICoLPgwpwciS
ZzUJT3OOzIBxZyWrYjKh8YUhInp8U6zyrWHqb/a30aJHnJXGG8EyrMtn+zwfgxLV
yTFMJgaYucJF9jdRK8nHXXAhplNsHgWi5+AGrNej1QMcfXAvhWnELFLZg4v23bm9
VhP8RUm9hIUCz8hWTvg7+EYalzJX39VO0OzSUV/WwefyqklZJwXBJ2yMRBF/vwIt
XqvO5ePkqfA=
=nTrR
-END PGP SIGNATURE-

[PHP-DEV] PHP 8.2.0RC5 available for testing

[Pierrick Charron]

PHP 8.2.0RC5 has just been released and can be downloaded from:

https://downloads.php.net/~pierrick

or

https://qa.php.net/

or use the git tag: php-8.2.0RC5

Windows binaries are available at: https://windows.php.net/qa/#php-8.2

Please test it carefully, and report any bugs to
https://github.com/php/php-src/issues

The sixth release candidate, PHP 8.2.0RC6 should be expected in 2 weeks,
i.e. on Nov 10th 2022.

Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/81b78cd31b6e74b6a7ba791f62f726a0

Thank you, and happy testing!

Regards,
Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.0RC5.tar.bz2
SHA256 hash:
0c20a018520531f8fc2fef47131a280e26c2c0575b1b724b5d6afc61ebb7695c
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmNYIeERHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adxIchAAopdMvje8Oo7ImWIDdTFwh2oxqnshqT7d
F38iu0KXpAGJYri2Gkr9sCJzmicR9DVYFsl6irHQj2SxIu+UupKd9Q2OM75P9t+8
ZsfIKS+n0Z23eOe0GYRWgKror8ll61rhrS0tliQjvYgXAfNrOydN25zcCUJG/P1r
nsYBCPs378KgHzMgAWQobh7A+725Fupsdd1otfAtIBfmsA8ui/HhXRzTlCVNRnsU
wJbUQ1nGPXemvsZXjP+DLhKFzd8U4gBD+YAD7YNiCWqN64xy07nqGge9LX/5DQl2
zldeEAW+15KAOCrzkYW2z7HNpdrCv16KPcitiEMFVFXTb+yLi0cTXw6szw15WmNZ
pMMsip5Et2q31RZwr+hQOYR2PHR6aavn5eGJDhd1mM5NIqz0IEvCgGbhSp7G333G
DyDQ4/sAH4DaqHl4Dp13mW7CWvdiPP7V5XfYXK7klaBa1DMtHMiaMPOa2zZqcXSd
pJk5k8/W3utFfSyFmTOblGT/qQwuN7UQaaTFNIthhk5DtxNVJKWlyHY+ccNBI0so
6Rr6RL7rLNZ14hCU2aCHLn6eyF40lenLjyqZpXZjmOth8tBeXRbeTyJpP4AlPZgq
OF99OFV/XUVPBehFb/PeU236biD79RwwoWQMYz81+LnXfMbzcpnKmaVHOYZLS8Wd
kKycArBGFo8=
=mZfZ
-END PGP SIGNATURE-


php-8.2.0RC5.tar.gz
SHA256 hash:
c879b316d6f9c06ae6c6d7a418d94ddd569f32ab06c13d6d8ffc88643a0692ec
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmNYIeERHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adw+qg/9EwwXIZpGcAghX5f36k/ikRphBT8CL6f7
JSrk/mD8cYJXgGDtWA6oYtBkg4++FFayWBxhm1QTgzRHWWDsz/ip+7raBv8N1V2V
bQBf60qnq0FfTkGS+jWzPtIf4Rp+2obB2LbpxUSztA/MtY8sVu/QQb3BzhnKgzP3
IbVj3FZU8Kz3k3/7UY6MXfjfXUjPOeepLoG88omcdwlqcWjzC3Mv9r/vDv3FzLzl
zQnAvKI9HzOQYwCBXsekzj0Lm/skqGPmN/2sKVyhtlP5JnWge0lmw1jEKejxw5yi
N8TVhpVk4KnHvOKmneys7TBFpF1Jzxb+DqPLHcbZYe7GTEAaMchMw8H8XV3gtK52
+Z5Vw2Db+yYzOA8imcyZZv3PkvMkgXw9MzvnyzRyyW2OE+gJlRI9kxUdqU+bMCMk
Sv6B9PULMtRwMK/w96YBrY5kCZOYMwY3aEGs2lWueqKMPijBRBN94+6J9D+jsa++
t6KmPXB4YWr79DtUWEnid/ElROv5TCiFX4D0U21LOj23XQmAV6nCUj6+Zls9XpYX
x5gpvVDJ88IDP+2Id7Ha69XARmyu0Eagoxe6mSXoG0WjlJRegr8ehHZ9qWOVmONe
+vL5L3q3cYk6r8vuL7jxfDtD9U0mwGGLSESB6vjT+K2OfcdHFKTIlYQ/5/+WHjIM
EE6Vyj80kSU=
=qYza
-END PGP SIGNATURE-


php-8.2.0RC5.tar.xz
SHA256 hash:
5dbd72106664b3588a047da557b6a99a3cdfcb83de9890cc3be9db5af8e4aa0e
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmNYIeIRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adyOhw//T1gaLwwtuA8b0VeoJeLyky/JPOQalHsA
EfzGaJvX4r9o+N1n63/NS2bUGltxW9yJ9khDN0oVEuylAsweyFRDCpBt+b2S2laq
il1FVb6mT17pYnx/1oRk9tornPBl13Mxz01BDM2aQvwzqsxusEZ/x9SSEE0eUGTL
c7jjKSuHkHGsbkMRBOib5WTjAcB+aWm+ksHRuhdGr0HbThmMlHhLntPfonvGUHZw
nUfl0f+7jCrrnOJ+pkiRQPPDzzP4zjd0SLhI1rJ8r/xK0aVMp8A/yyetaKpmf9zi
cqksVFC2r589bAK8latWNFQ9+paR6/9DPZ1F6Qc990irD6IJS1tyv5KFymN+qjbT
RkNI3KZq/KzIF8FNE1ZjF834UVIsh8tldoN1F/GSQomngARsl+ocO+8JCpCFvFWD
y0pYaQ/Nv0PNU75ldjNJn5XihItS5VrxM517yiVWaAcP0/g8pmYVyabixkywPQWN
qZ0BZ+71gU/oL8Fy/Cs01VhtQej3FtTJUmVktHNrGM54yHmSHAMD9KHu3Y4pt+iL
CTn6A+k+AoM/7ADoJY6tREr6SoFJkgRNtccclQr5hl8D7lmmX8oZb1Hd2Cg8yhIc
SqPA57Pvwzse3wLp0JZcfKtI3N14NuLUznUUgOhi24ogaW4/9FZbVar9/gA9xIfy
2LJ7hzneyUg=
=B197
-END PGP SIGNATURE-

[PHP-DEV] PHP 8.2.0RC3 available for testing

[Pierrick Charron]

PHP 8.2.0RC3 has just been released and can be downloaded from:

https://downloads.php.net/~pierrick

or

https://qa.php.net/

or use the git tag: php-8.2.0RC3

Windows binaries are available at: https://windows.php.net/qa/#php-8.2

Please test it carefully, and report any bugs to
https://github.com/php/php-src/issues

The fourth release candidate, PHP 8.2.0RC4 should be expected in 2 weeks,
i.e. on Oct 13th 2022.

Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/d1e85cad30593765c73042f4616b2ee9

Thank you, and happy testing!

Regards,
Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.0RC3.tar.bz2
SHA256 hash:
3563c27710ce82136a5326ef915b1a006c2d3c7d7a02b424221ed38a01a76199
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmMzcNQRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzTGhAAkEvt+DRZiVzmDDfyXHoYWksqApHwC1N0
DcoPee4OsYFksZ56uJiVScqSANFHYL0MV/qCe9/Y30Kb8P+pPS22pJ4ffZNgynD0
7oRC0Wzez3M1HRgjo/kjtU2BGKnNqWOxMDT8sO+fXE69Iis/BlDEnouNBgEJxvH5
3lCdRVbY/v7IkwkTMwMPFC6+5X/8bxUSOaEvFWKLs5k61Wjzk9NIRL8fbtmtXFPM
pNGeiY0zxNuD0y0GKSnBhOLKn3cl2PkJYPP3kv7vhV2fvkGFVnAAxiSET0yVodzN
LZ3DXo6A2LW4DeyWeYCtSgSskFuT1laELdMJTA0rOqHjEb8ieiYas2cp1yYdbIlh
KaTcWbMBlp2kewC9oEUnT+sQaklpYupAfj5Z6qrg1fg5iY5znYgfnsgr3d30/dP3
nKwfC8+dF/8ylE/oKqnP6itIEvvnO5ngeCBHc/4XADTVaURSRPwkqfItdvNG33/o
BPsWW2MkuqGj5y6WEPNykpSqJRZCzScZJGLyViXhOm55TQv9c9nyud1ank/+UAWW
ZmXPtkiOIwqlxsUI0wkG+pzlsWhEKGAuN3FBQb2FI3lji7Gb5w++hVpZ/Y8Yu8+W
F5lR0s7hxxwFkDZ1kf2A6Gc9dU5cxQfKVzTGAzKbTKhdSsFL+iUv22wtLcs5OrN3
YZqOu/fyNcU=
=DDRD
-END PGP SIGNATURE-


php-8.2.0RC3.tar.gz
SHA256 hash:
4a9b27e1d7f4c0c3e6eb8a69870f488d90768268d0098de1b2712946fb50ddb5
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmMzcNQRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwS6w/+Lg0VvgtXiWId8cHkd92c/YP60iZLXf12
FvKB6Y+Pt2EubZD4L+9BbkNgdkE6DEZbP8L7XXAzwSbRXLmsvpc+z+MwNxix7jBJ
7c37wmd4DwxO3/j+crzpVUSQtaPH3N1tGuwtjAMiFT8B2di0SCe7H6F+TETp+OUg
bvTBuSxDltcMlSijuwLM/t6er+Ns9JWu9nhrvNvexZw3j/ynTjrE0J0942sHMmjp
bdo/IvV22Qhug039RrnIylnVQSni6gUsaLBzmuDLJwuwxEhtC8aEScw6bfFLRyYV
BmRLlb/2P0Rd6CigaN3ZDgkRuHomYBo4wUjUbxmlZyecZ69VO1tEXruf22eIEKdp
6aGPyeojQUcOEFBbHBY8OpCe9woVawvCbThuTKmpZf+LuVI5a9XZpDSc6ogjkhDE
ekokf4glWqQyxO+MTvx+F+mDH/TnAVLGNuVQJ+Ja3uwOJpJ/ioRmZOazBidjWhNy
ZRT+cVZoXoiJ9ATwsqDYX6xtOF/ikMNZHfbcM1jqC3GT9nZ+sxuKiEV9j1f3AA8T
KV2s9gfEtAOCia/pLqioeBS/w/3beNYT3+QFKsRWt0/nmeq4KZ5a1j/11Srz15Jj
S0ogH0fOjFv69Ql3akiIJTDfkLyc1P2i+tkl9Y5jcjNUbJ45HNOmT0ga+IcZuoW/
8IOjqcxPdRY=
=7IGL
-END PGP SIGNATURE-


php-8.2.0RC3.tar.xz
SHA256 hash:
9965c3a339bf8f1e7d3dbaca8d8438285b6d9d09a01e1adaba6b357c5d8b458e
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmMzcNQRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzAqA//UPC0XAWbfMmJArr1mYa5d8VNJuRi9mIH
5cf0AYcRCvfPzJAgxjW0Ai8aM2bnJBUzY4aJkUEcE+O2GRhHF68171EIuUJzP27F
JttfYF1KHA8VcWZ0CuQTG65HfsHfFJRC2c2XYhOX8DQg37fr8C4eVKigBiriA2hG
dRkMnYKQgVP8yRXpsepiE4XrM50De1kDhmyxfk80G6n5Rn4Rg09GKqijzze9lK/j
H2zYvBEm0UtiMfu2ApPhMYBk3fGER+VGT7WEbF50O4lODhFiQSLXwvzGyvdPpPEW
hUxgdy0cjYdF68d9sz5s5KjIDBbo5C3jut9uc+rAG97etu3CQECkEniVFrerRiZM
cycoOxNqDw//c3R1qeszadnxUKhgsk3F3zDcsJQep8E7aWwotGmf1DX2r4sUGsMl
zoA395WoLgFilyXRrz8vY9+htx+T6YsciQwesP+wGuYhHY97VhSRYKjAVh0qekfv
fvjouIeX8WU5xvMdJkWu8LXacGg0z6ektQUMPKkEJ65WdqfjLlSL16Z25chJDovQ
C2aL5lGrkfobA31RjE+dgD1gC3I+8JRO/ThXJPjaaYO80zTtySfOgj/8Oc0QKMOI
3qt/wxub2a8uqOCWhYxheK4MR6QI7htm/pZQF5f/T56KJig0P4uOoML35Mqj/+Wn
4Vl595hcHUo=
=OJdO
-END PGP SIGNATURE-

[PHP-DEV] PHP 8.2.0RC1 available for testing

[Pierrick Charron]

PHP 8.2.0RC1 has just been released and can be downloaded from:

https://downloads.php.net/~pierrick

or

https://qa.php.net/

or use the git tag: php-8.2.0RC1

Windows binaries are available at: https://windows.php.net/qa/#php-8.2

Please test it carefully, and report any bugs to
https://github.com/php/php-src/issues

The second release candidate, PHP 8.2.0RC2 should be expected in 2 weeks,
i.e. on Sept 15th 2022.

Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/81e5a7c88dfded5237fffe0341d5d5d8

Thank you, and happy testing!

Regards,
Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.0RC1.tar.bz2
SHA256 hash:
baa8cf5ecfc97940ddb9a09734d1eb69242e7056351517ab246a78f0ed0b0bdf
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmMONR8RHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0ady41BAAhp8gJnNbd6ais3M3GElEqMZurA1SWpXY
OXa0VOnZFesS+v1VeIvVdJrE91DYeNtX+Kz+Pb7bCFI14huvQ4aWYfyigGxPewx4
uJoCI4qVVUZ+LmM7jH7Ieh5+ftm9SpOTNSsOJf+1CaaG/y8Ig56VCYMPPDOCHqoU
ie0sA57VXC34ePR79XTkz7h682ZSZSalM9rpzXrdDIsxGb+9PMRhiI95imM09QGF
W/N4KGshyzCeznkpRWpzSVbLpznPOCyno6SZDEcfSZwPI9gJSE/IgSzdayTYRiky
preGWOX8L5dsnG0UIETmEc32kEhAH+4eOwb+oahKzlvuvMeHiKIrLsO0r+4woSb2
UzQYUAN71ePjd8m+rWuyLE3p8qhJ4unAwk2Ibz9vixUq3jqEj/Ja6/VUz15uyKwO
AE5UyZoQdKNcC9Y2rzQmNU5ITnoLdaasI94l99hzIeTelmBEs+Xa097EadPOBKJj
fhjFdZZ4j8fDTH2s1gCsg9w9jHAzb/alN1tBLh0HILIiIjswRcPFlzxqmrrzYTXP
npVED0qpwh+WXwnIrRwX8nxwUVG4PpRRG0FtnG39pkZVoFO3gpUntVBe/dxCLAut
+EYXP9FJMl8hbkSpYBT1d/CK/1EK0l2htThO2vglDZL3d/7ZDjyyeUld30+cWg52
aOGD2iSIF94=
=jLx6
-END PGP SIGNATURE-


php-8.2.0RC1.tar.gz
SHA256 hash:
487b20e853f9186182f8ae5f4fc9700f2c829a22b7598526cdbf0304d57906a3
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmMONSARHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adzztBAAoi4MuBKLdy0a4J5gWILZhj2yCQe5yoRU
KgDf17j4DRwuOumD8lgv0dR4R4tbCV9oLwKhFRglc2m2AHEuRSAejUxStmpSpTft
RmTrTRrRePNyzoRW0E83u3g0teAwVuTozhpTHQUNMQnwkT/Aa1chu1/P82Ifh+wK
E3AMIv4TuAJfRVoFY2yiPg7TKmRvgiiXDrD0S/p/UQvxF4S2bWcelyRdTArinrZy
bf7bVCTecRRQOmUygAUvVrcmw2kkiyxLgAxV0aOXXJwr1lBd1himW+I4bqCqpcKS
8xxrPYjOEhV3QvS0klqGDf5fxlTDGeoWIXLidlSVLcaGS93CpYRcul0njgTd/ZOu
q+6fcHO8FMAI/vhDyp2fUVT7kEnDT1uX9+fAHp2uOfnfaMphkL7/JtQhvy3tzRZp
bnSO+yHOivRqXk6jMSFh0lcYgWwPZ6wJFbvSIro3SeZ4IT29nfhBz1MD8BSigdfh
eh3yCYgJtnWaRo+jkK1TQHwQOq1F7CPaCFXX93cr0YCICoi7aw1TpLP3OMzRoWGe
01t0qEvH8Cab/6a33ashF0GFlR5lF4LEYV02TidnXIBD3t6q44J5+rb0Cif+eU5z
ACqbFqHIflRTHU235EETL27MHqgPgCGNpDXGWpD0cChOT1jvlGUlyGOoS3WtDVvT
esn2Y07ONjY=
=gisR
-END PGP SIGNATURE-


php-8.2.0RC1.tar.xz
SHA256 hash:
93bb3a0b377167e18813e9c829d8daf1611161d788a27c5057bd23c9846ff6e8
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmMONSARHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adztUxAApSkVKYCK539uitc2VZsto+s+c6a/Ebqq
PU7Z5NhWQUftc4NSyt6ls4AMQ3hT2MDFH1WZcuGqA1U77YgrWg8C/od2MQhAFype
ThLUTb56GN8rUVyi/MEFr3Df23UDwZjZ/aKQ7UNxKv2KV0I4/fGIRp8tDRlkvEnG
p6Cd1gu6Suu0boxerw++7L87KVfh4YHuFV69Mg4xT8iq59tSDTr5woYLG4KvxrCz
lm7IL9dmNCsfDVZmEznLzIm/cAbD8+S2PHTvVe4YPky5n7VEjbwwvCwAf/h/fqge
QarwEBrGG8PCTwPC44yfIFZR30WW3JzuIcOoyozeWAW7TUSriPXt+JBHLMG/B2h2
SWE+XFfU+TVNe9ngBB3PhkNZCrerjEjJi3bbyrHYSiXXDyvuwOxjn6AFh5ezCSe5
i7fs/5O22FT++Sd6cMhXlFOuU0mxfx6bAlI60vBIJ8Ghhk89+hftwc80giu3zZuV
T3xB07uGNhxBh3gm/Uo9oeUqsXIpy62xNLCvOamYk7Kr+9ZU0TzgXBjxhbn0q+Qb
2IzZD7KvVd16SGO6RnjMNnaALG78fXNei0qwkZ8dB/i74sTH5nwUiwL0YrKyDfDN
znXa4Mwaupbp74jt2RUQ2pq4OBrm3IIqkwjpSPJj5OnVFv+IpnAEziRIiFddpYdM
9VjZaJTfOfI=
=h6nh
-END PGP SIGNATURE-

[PHP-DEV] PHP 8.2 branch out

[Pierrick Charron]

Hi internals,

We've just branched out the `PHP-8.2` branch :
https://github.com/php/php-src/tree/PHP-8.2
With that, `master` is now open for PHP 8.3 development :

Please remember to include the `PHP-8.2` branch in all merges
from `PHP-8.1` and earlier and commit all the changes from the `PHP-8.2`
branch to `master`.

Kind regards,
Sergey, Pierrick and Ben.

[PHP-DEV] PHP 8.2.0 Beta 3 available for testing

[Pierrick Charron]

PHP 8.2.0beta3 has just been released and can be downloaded from:

https://downloads.php.net/~pierrick

or

https://qa.php.net/

or use the git tag: php-8.2.0beta3

Windows binaries are available at: https://windows.php.net/qa/#php-8.2

Please test it carefully, and report any bugs to
https://github.com/php/php-src/issues

8.2.0RC1 should be expected in 2 weeks, i.e. on Sept 1st 2022.

Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/37f80d10531f0250f4111a7b3034e357

Thank you, and happy testing!

Regards,
Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.0beta3.tar.bz2
SHA256 hash:
2c09e6a3122e7e8ff9ccde7fce3199b5a1af72bc4e3dd603f2ee6f794e0f2da0
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmL7vB4RHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adyyDhAAjjqh8D0vHsRcHWB1/7D4RDzeOFjr6L+I
uJFoJ5F28zMEZQwgYCFGBdX7DZQHi7Ya6jNEdwN1xCytM06iQ16s3N7v8vuMiPxa
Axjz4NKYRSh7sSBhMfQCjEVR35ZjxeG3DOAC2teGMGnn6KkP06BZcjQaDmKyChuj
P1gV3wv5F5NFUfMEWhoQ6Aa01hu7L8FLoEhXIfpg2Hu0/1g7xLuoaI07Qq0GCHlK
gggsk8HYD8X9NQjdb1aaLuuA5HkVG4HLAsLmQA9YjjssN0aA9V8tI6b+KkG6o05x
HcRGncQF+nhJ5XrKJMaLwnbARupCGbb47Z8Pr4J3hJ1FfBEUEYv/5VUuqVfsOaJd
+ltKpcQKtMByFGDaLi3k7g5sQwx9DjEzd4clFwMIk+Q/Qzh8KJXQfdurGQmN2HeP
5ywjTDqF7ZLP62LQ8pbkrmDrwegKAyLATXPxdE0p82nSqiIUz+JikAu6U+eutuaE
+0BmEQbtS85PIx33E0ODuR99pkw072LJ2vg6IIXvtpy/5x27zZpv4xm3Xh20drV0
v0ufgPHHu0YCBPxXMc/26bTzYLQu/J2WgEK5p9BznPuqXyLwEOZImG7jEzY912OE
9kORg+mVMGQ6EK4zxEIqfCOFmuV80To+8RBDXl3TTjHfmYuulmHmwLbgue5TteDP
MuJiD4DplPQ=
=v30c
-END PGP SIGNATURE-


php-8.2.0beta3.tar.gz
SHA256 hash:
4f38fff5361bb597bd36c9652a78fed7a2894bb91e6bf126cc7793bc65acadcc
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmL7vB8RHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwcGg/7BqDLxWvtsOeOSw1vvrIx+KL0MnTPhYLC
Sf0eJgaEAmUBfWdtzcxQkxSdbu7TCz6fyGOjw/r9dhTuS1QV/SEwoMXauiYtIcZo
+TWrvQWXO3rlY/t5qjMT18oAl67VL9gA/IuBnFn+jJfvEFBtwJRxRpd2husE3tE0
mWvQ2V6YOSMtxBnMvqdL7cLrhC4A1u9J5ticSCDolurYXe333lC86GE3AvO9gnG9
ib4v+vZhAhhan082ani3syGIwrJLoV8jEiaN1ziPMuRVMmZZn7s1mGwPdR4JGsg0
4tySGKXswI+LtHHTd+B3HJlx58xQfj5gNlbB5TCqLLsQk8n408yGzrcFwSUSJXGS
neayIpwNc5VXfZDbm2Q1kDwDtZlPnb9WL7vHcVqhemSF1DjeBGOpCeHzO5iAv1T/
rQ7DiEpZBKQ46dmbSx1OdtIMmLWWWyuUcQZy788BuddYNBDQvRqqTLjPbu7M37ac
Gd8yXTWPFh2XFhTKoncJZ5+tuxS5ljsEAwvK3cwgYmOBa4gpxrTBjd/ei4XCnsEU
TBz3/u4BaPcPNOhnRDqMPfq8dunVqjHKGxRHAAWTOjZ6Oytyd2COnySQOrkaAxYn
nh+cf6nxBBnO47pIlpMoOdqDl9i2sI1l4qG2IbCD5TqUoR7c4yFZopD3NdQz7g08
sLb15f8CiNg=
=t4ew
-END PGP SIGNATURE-


php-8.2.0beta3.tar.xz
SHA256 hash:
bde43567f3f432cd35fa4e538fe248acba025dceeb92081a8c69adccf197e747
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmL7vB8RHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adyZVhAAssEtW9Wrc4C2fpNJsRrMJMrqO55LfxS5
+h1xKuCQ1xX0/MuFlA8rdsJuhy+6GdFgzYLQT1paugBZ3gI+RzwzH1iJPxqfaqlv
wRVjRHDz2OUgU8I4KPGFwK+794DelgOgFw0uBdk6AjnUnojlIqE2tMih13xHQ2qm
9/ic/SW7dFyd0DZFIvIAJh3Lg3dETI0BYvesijtA/JT+p3hV7/tU6jk4j2v9B/OQ
WMImzVsEQ7GM1PDKylHjVSWAWV6ogIEJV7Bvx3HMrIv07T5MKfUOMnRvgwhcKFnt
+/Lx0ZfigynnkUT5P9ede0HwBm+Dz03R+Kk8NGFxHJsqt8D1TaFkrC7tuYapze7Q
0lBfH4M9K1MgkYSpwNt/c0hhtdP8jKOn6Ojwyd3wJ/nigAikd2pMeipl1gmvnfHk
Ba+3zFz9s4YJ2DGcBgQtD7s8hkUzrSBfzMalGO5mHLo5JKPFtB0ImN/sDwLkkKt+
DoXk8VIdmQXYGzck+s7O6BxxTwFjhNRrxUsJx99DgKMYKOilvDD6SZoVCRY0Wkd8
/ens4DJKmk1PeuD3oqsoWaMC72C0Jo64waFjvb/Sc/aRsiMPd7tfWPPQGAFN2o/a
6jSB68DJqSCrpGZO+SUg6DYPXzsy40vomsAfCH4CaHmRlkvDA4takOkxBHVmZN1h
CvEATnDxC+Q=
=kC5m
-END PGP SIGNATURE-

[PHP-DEV] Strict properties and unserialization

[Pierrick Charron]

Hi internals,

We (Sergey and I) would like to introduce you to a problem [1] that was
reported by Tim Düsterhus and others about the Strict Properties RFC [2]
that was implemented in PHP8.2.
The RFC missed a part about how PHP should handle unserialization of
objects with undefined properties.

Example :

class Foo {}
$foo = unserialize('O:3:"Foo":1:{s:3:"bar";i:42;}');

In this case PHP will not trigger any deprecation warnings but it probably
should. It was something that was not thought about while writing the RFC
(at least the RFC doesn't mention anything about this).

PHP8.2beta3 will be announced this Thursday, and the next scheduled version
is supposed to be RC1. So we are pretty late in the pre-release cycle. We
have multiple options :

First we could just do nothing in PHP8.2 about this and leave it like that
and only fix it in PHP8.3. This is probably the way we should do it if we
want to stick to the initial PHP8.2 release cycle calendar.
The second option would be to fix this in PHP8.2 before RC1. We don't have
any idea on how big the patch is and it may influence the final decision.
If patching it for 8.2 is the best way to do, we may want to add another
Beta (Beta4) and delay the RC1 release by 2 weeks.

We would like to hear your thoughts about this issue.

Regards
Sergey and Pierrick

[1] https://github.com/php/php-src021-11-26./issues/9186

[2] https://wiki.php.net/rfc/deprecate_dynamic_properties

[PHP-DEV] PHP 8.2.0 Beta 1 available for testing

[Pierrick Charron]

PHP 8.2.0beta1 has just been released and can be downloaded from:

https://downloads.php.net/~pierrick

or

https://qa.php.net/

or use the git tag: php-8.2.0beta1

Windows binaries are available at: https://windows.php.net/qa/#php-8.2

Note that if you use a ZTS build, this version will NOT be usable
because of an issue discovered in early testing of this release.

Please test it carefully, and report any bugs to
https://github.com/php/php-src/issues

8.2.0beta2 should be expected in 2 weeks, i.e. on August 4th 2022.

Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/81f41a2b833275bd2d00b7165907540e

Thank you, and happy testing!

Regards,
Sergey Panteleev, Pierrick Charron & Ben Ramsey

php-8.2.0beta1.tar.bz2
SHA256 hash:
ab7292701c12393892cfc7c2d93f8d2701946d073c87a1e05619da3e04a009a7
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmLW3BQRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adxBvw/8DxXzR/AUqkEtIVPwoOXmZ59x6DONPxZ2
7pMx94ZU0FJFvUGbOzlFIQc2gug0RhCEpxRbIFg7lj3gkXZAL6CRFS86jF4N/nR7
5Pt6rtx2H2uyX9a9DhCa/7ZKo0fuTz2ZDemwPbRom8TkRcMSysW0lmHplKQ3DBOM
qk6jb/chFiV0VNYfKqSJpftvWFMMUwqRRc8Z2rmyxoRc2gh6ak+aK0TVQR4tMEhP
coQcY/6CaNkR6e6pgjHpUMf4eKw5gYjE7Fyw8ZxUIk1zwlsbz0MeGU//xpUqW0br
0z/CxPg4BdGjGUnqK1nBbubZJnJa4q7TRLMkyskEdFGSuEmVvA8MBsKTsXL8jtp8
jh6NaTfOi8kHHYCTMBhS9ZmkpAxHGDc6gfEiLQOQbPHj81wb8qYjewcuDIYhQJme
kKI7av7uR9XJWXyOuSd9NCtW1X57K8Ik9NdpTU4PvDnaP1J+w3tT5TGSOPfc+XC9
V3KmIW89Ka/Y7E/RhdqQzuNIB130YMbN1NTpbeSia+udTNzy2Qc2kks7B7PzEsed
gzC+Ae0kXAUNn1HdVT375fX4vAiHjfkqlF85gj0/Ke4PEp48yiM5fEJGl3CW63Ft
MeiZc/38G4Dbfwhm+V5KJ+C0RYN6a6nSaTcvs8/vvRHLGjCyRPahMe2stfWLVrK+
LnGPL67V0iA=
=U03r
-END PGP SIGNATURE-


php-8.2.0beta1.tar.gz
SHA256 hash:
0eea12122debf8e291cec2d82059a29e61ad1a145458d0ae82d7cd11e10277c1
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmLW3BURHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adxr6g//WfsPtgsgrWlG0piHHisggeNCcuat6uBj
A+HW1uWdhhh3mVbukTtLkLt5fjTTWY8DME0ltSYJC7aHmuXL5SvWrtyWSSNKVaxw
5GEra0KVE8hspHofZnTp/sFkglKgE9xCA4DAZ3IsG/00hK2++GQVC9fvhvRGAO9s
S2e8xotKZFpqPrWrpM8WVeSr9jF6281V13PzvfaPHDpyke/SPdXaeaPE5slwX+HP
Glq6gHHSzsD6/pmi3tXt+tcDU+5C3ydB9/CYYzGa/+28yLHCJoxHVlGqOTqJ+JAV
eqMbEO+1QNo8Zwd7A5Yb1uxRHZR631umhijmfshqKyxwtzKt3zx7XdeZns+XRVWY
eUx0zy3UUEAO/yr+R9yLQoa10akhP2ovPlZh0NhMN6AhKgvAJ4BikYNPxqyJVjCz
YkSge6cdQhL/9SGyMws4CnG1srioaG7YMcMa+Sm7bcrDMcsvgtkSyMJQ5RW6jFeQ
ucLFSCmhcP7NGpk2ZE97Ec7I+3A9b6xNiZyuc1MjND40T4ZTvNFJpa4UgZDHVQGe
jgl2nlMEX9/D+po8lVR6dTAXbQBeKA3M7DRPZ7SDY6qDLW1EBSHps5d37cB39dFl
MPVMxgHpu6L/BrOiVgSS2KYB6bbxCqJj49sNvsbAXTfALEEZJ0M6WXny30cLBuAY
ZR8/B8RKzgI=
=4zcC
-END PGP SIGNATURE-


php-8.2.0beta1.tar.xz
SHA256 hash:
46ebb4be04b98833bab649314775cc100bdd825c73d9bc3646df5c1ec7ebb2a6
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmLW3BURHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adwT0RAAgzp3wTWnrEW1SeLeTL+PcNQjaWICBXzn
UyJAwQ8ZmXA2PUEXZ5X5Z9uuBDHwTwAQwsFMU7QlngINjflADBKrIABA/ggd+dYj
y3nwievm3d5rgW+RiOddmb6hbnePCggPNPuIb8Tn3r4hdGOcilSwl71oBsolVjW+
05h2UbPo+vB6Q+8+H8WGRWK85R0OYd1bTfZ9KXkM/oH5S+HlI2vKPBDRZCJq7wZj
JCKjIZhSIthJN8WQFmyizG91xdSn2t3T/lXouVeuXiffEVT8S4njuS/QFG5yd2KL
3biNBo0MiLYdDiTwOJDCh7vzLi1d9PUyYy17auUV04dMat76gxO3DJZJoivVu2E4
yQcgnphLbZ2iCcBZxr/qYk4Qmy7H0w1eMsCpjh/vXFeRA9pSvHpXBbpBCF8JdFeh
T49Gxv5oT+x08o4dDkHotuY+rUmgqZihTc+/7zZ1a9yi4PX6dDChAvNV8vONW9hH
FIA0k0QkRVe5U44pwq40c+AiGh06iqLAhif6GL+hJfIa/lZ3EHlqrTfpSIpEDfBt
D3LIpGt/U/GYstk8P/1ifNxsryrvJ50t59ZJZzO+MT0GRAyTs7L+raBABTKmBA8W
jcOoxinkKY2PUkL43JR/lcDUgKreEaE/XhcN0z+DBRCmxDGbztyruq/MUCCX/pAU
dp80G8sSJz0=
=pzM+
-END PGP SIGNATURE-

[PHP-DEV] Re: [RFC][Vote] New Curl URL API

[Pierrick Charron]

Hi Internals,

The RFC has been declined with a vote of 10 in favor and 14 against.

Thank you for the votes.

Le lun. 4 juill. 2022, à 19 h 34, Pierrick Charron  a
écrit :

> Hi internals,
>
> I opened voting for the new Curl URL API as part of PHP8.2.
>
> All recent discussions show that we are not even close to getting a
> consensus on how the new CurlUrl OO API should be done. After changing my
> mind 300 times in the last day, I decided to only propose the procedural
> implementation that stays consistent with other functions of the ext/curl
> to target 8.2. I know this is not the ideal scenario, but with 8.2 feature
> freeze in two weeks, this is I think the only approach that will not put us
> in a potentially bad/harmful situation for a better future with ext/curl.
>
> The vote will last for 2 weeks and end on 19th of July.
>
> Regards
> Pierrick
>

Re: [PHP-DEV] [PHP8.2] Feature freeze in 2 weeks

[Pierrick Charron]

Hi Rowan,

Thanks for your email and sorry about that. We will have to check on how we
can solve this issue in the flow so that authors can change the label
themself. I changed it to "Waiting on Review" and will make sure to include
this in 8.2beta1 which is planned next week.

Pierrick

Le mar. 12 juill. 2022, à 11 h 09, Rowan Tommins 
a écrit :

> On 05/07/2022 19:08, Pierrick Charron wrote:
> > This is yet another friendly reminder from your RMs that the PHP 8.2
> feature
> > -freeze is in 2 weeks now [1]. All RFC targeting 8.2 should now be in the
> > voting phase to respect the minimal period of 2 weeks.
> >
> > Also it would be appreciated if some of internal devs could start
> reviewing
> > PR labeled as "Waiting for review" [2] that are in their field of
> expertise.
>
>
> Hi all,
>
> Could somebody please merge / review this RFC implementation to make
> sure it gets into the first beta: https://github.com/php/php-src/pull/8823
>
> It's been manually tagged "Waiting on Author", but I have no way to
> switch that back to "Waiting on Review" now that I've resolved the
> comments.
>
> Thanks,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

[PHP-DEV] [PHP8.2] Feature freeze in 2 weeks

[Pierrick Charron]

Hi internal,

This is yet another friendly reminder from your RMs that the PHP 8.2 feature
-freeze is in 2 weeks now [1]. All RFC targeting 8.2 should now be in the
voting phase to respect the minimal period of 2 weeks.

Also it would be appreciated if some of internal devs could start reviewing
PR labeled as "Waiting for review" [2] that are in their field of expertise.

Thanks again everybody and keep the good work !

Regards,
Sergey, Pierrick and Ben

[1] https://wiki.php.net/todo/php82
[2]
https://github.com/php/php-src/pulls?q=is%3Aopen+is%3Apr+label%3A%22Waiting+on+Review%22

Re: [PHP-DEV] [RFC][Vote] New Curl URL API

[Pierrick Charron]

Sorry about that

const CURLUPART_USER = UNKNOWN; // what UNKNOWN?
>

UNKNOWN means that the value here is not relevant for the user to know. But
for clarification, the values of those constants will be the exact same
values of the same constants in libcurl.

"All errors of libcurl will become CurlUrlException."
>

You have a small section about CurlUrlException, but if you have for
example a bad port when you set it a CurlUrlException will be thrown, with
a CurlUrlException::BAD_PORT_NUMBER error code and a more user friendly
message.


>
> "Setting a part to a null value will effectively remove that part's
> contents", but the $content argument is of type string not ?string.
>

My bad. I took the liberty of fixing this even if the voting was open since
I don't think it will change the actual 3 voters' vote.

Pierrick

[PHP-DEV] Re: [RFC][Vote] New Curl URL API

[Pierrick Charron]

Sorry, I forgot to include the RFC Url :
https://wiki.php.net/rfc/curl-url-api

Le lun. 4 juill. 2022, à 19 h 34, Pierrick Charron  a
écrit :

> Hi internals,
>
> I opened voting for the new Curl URL API as part of PHP8.2.
>
> All recent discussions show that we are not even close to getting a
> consensus on how the new CurlUrl OO API should be done. After changing my
> mind 300 times in the last day, I decided to only propose the procedural
> implementation that stays consistent with other functions of the ext/curl
> to target 8.2. I know this is not the ideal scenario, but with 8.2 feature
> freeze in two weeks, this is I think the only approach that will not put us
> in a potentially bad/harmful situation for a better future with ext/curl.
>
> The vote will last for 2 weeks and end on 19th of July.
>
> Regards
> Pierrick
>

[PHP-DEV] [RFC][Vote] New Curl URL API

[Pierrick Charron]

Hi internals,

I opened voting for the new Curl URL API as part of PHP8.2.

All recent discussions show that we are not even close to getting a
consensus on how the new CurlUrl OO API should be done. After changing my
mind 300 times in the last day, I decided to only propose the procedural
implementation that stays consistent with other functions of the ext/curl
to target 8.2. I know this is not the ideal scenario, but with 8.2 feature
freeze in two weeks, this is I think the only approach that will not put us
in a potentially bad/harmful situation for a better future with ext/curl.

The vote will last for 2 weeks and end on 19th of July.

Regards
Pierrick

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

[Pierrick Charron]

Hi all,


> - The new CurlUrl class should probably be immutable from the start. It
> was my biggest mistake not to do that with DateTime.
>
>
After thinking about it and some discussions, I followed Derick's
recommendation and therefore changed the RFC to make the CurlUrl class
immutable. All the setters were replaced by new `with*` methods.
For example setHost is now withHost and will return a new object with the
host modified. This will prevent confusing behavior where the CurlUrl
object would be unintentionally modified after being attached to a
CurlHandle.

Pierrick

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

[Pierrick Charron]

Hi Rowan


> If I've got a URL, which is already a string, what code would I write to
> "do some checks" on it, outside of a unit test?
>

That's just an example with an old version of PHP, but let's say you have
some code that makes requests but only to a specific list of servers, so
you want to analyze the URL and check if the host is in a whitelist. If the
provided URL is "http://127.0.0.1:11211#@google.com:80/; and that you used
PHP <= 7.0.13 your parse_url function would tell you that the domain you're
trying to request is google.com so everything is fine, but in fact when the
call to curl is made, curl would call 127.0.0.1. This one was fixed but the
problem could still occur if the parser is not the same as the one used in
the requester.


>
> If I'm using CurlUrl to "add/delete/overwrite some parts" how is that
> not "using it alone as a representation of an URL"?
>
>
What I meant here was that if you're not using curl, you have no advantage
of using this class alone to parse since the requester you're using could
handle the URL differently.


> If I'm writing a PSR-7 object, am I only supposed to use CurlUrl when
> interfacing with curl, and generate the string myself for other
> purposes? If the implementation I come up with differs from curl's, how
> does the user know which is the "real" URL?
>
>
You can use CurlUrl within your implementation of UriInterface but for the
same reason if you're using another request engine than curl, you may have
the same security problem where curl will not parse the same data. If you
want to make sure that your CurlUrl object represents the same thing as
your UriInterface you could build the CurlUrl object part by part using
your UriInterface. When you assign your CurlUrl to your CurlHandle with the
CURLOPT_CURLU option, curl will use the parts directly instead of parsing
the URL again, so you're sure that the host will be the one you set with
`CurlUrl::setHost()` and so on.

Pierrick

[1]
https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

[Pierrick Charron]

Hi Rowan

>
> Rather than a *representation* of a URL, think of the class as a
> *builder* for URLs. There are multiple methods because you might want to
> build the URL in different orders ("start with this URL but replace the
> port", "start with this domain and I'll add the path later", etc). All
> the flags are related to how the input should be interpreted, and the
> output manipulated, in order to build a correctly formatted URL string.
>

Sorry if it was really not clear in the RFC since I didn't even talk about
the CURLOPT_CURLU option, but this class is not only there to parse/build
strings for Curl but to give this specific object to Curl instead of a
string representation of an URL.


>
> Maybe it should even be called CurlUrlBuilder? That also fits with the
> design of having mutable setters; as Derick pointed out, mutable value
> objects are generally a bad idea, so it would make sense to encourage
> users to think of this as a way to get one or more strings, rather than
> as a result in itself.
>

Since you can give this object to curl instead of an URL string, I would
not call it CurlUrlBuilder.

Regards,
Pierrick

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

[Pierrick Charron]

Hi Michał,

Thanks for your comments. You made me realise that the RFC missed
information on a crucial part which is the new CURLOPT_CURLU option that
tells curl to use the CurlUrl object instead of the "standard" CURLOPT_URL
option. I just added some information on it in the RFC.

The purpose of the CurlUrl class is to be able to build/see/modify an URL
as it is seen by libcurl before/after passing it to your CurlHandle. It is
not meant to be used alone as a representation of an URL.

For example, you may want to do some checks to make sure that the URL you
gave to your CurlHandle is well formatted and that the host or any other
parts are what you want them to be, and that it was not something else
because of some differences on how the URL was parsed. Or you may want to
add/delete/overwrite some parts to sanitize your URL. That's why you have
those setters/getters. This class is definitively not there to replace
PSR-7 UriInterface. I can imagine some Guzzle or other implementation to
build a CurlUrl handle from a UriInterface before giving it to curl.

So this RFC is really targeted to users of curl_* functions.

Le lun. 27 juin 2022, à 02 h 29, Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> a écrit :

> Hi Pierrick
>
> śr., 22 cze 2022 o 06:38 Pierrick Charron  napisał(a):
>
>> Hi,
>>
>> Following our discussions we had on the subject of the new Curl URL API,
>> and other curl improvements. I decided to only focus on adding the new
>> Curl
>> URL API and put aside all other improvements. Here is the RFC that
>> reflects
>> our current conversations.
>>
>> https://wiki.php.net/rfc/curl-url-api
>
>
> TBH I have a problem with the proposed Curl* classes.
> IMO they present a mix of responsibilities that I don't like.
>
> CurlUrl is for me is a mix of Url/Uri object properties well known from
> other userland implementations like the PSR one
> with Uri specific like the host, scheme, port, path, query, fragment, etc.
> but on the other hand, we have flags and options which
> purpose is to pass Curl specific things but in IMO wrong place instead
> (for instance Guzzle use separate argument in all methods for options and
> flags.
> Secondly, it has some default logic like `setScheme` allows to put a
> scheme but requires the supported one, with an exception that you can
> ignore support checking by a flag - IMO this logic belongs to its consumer
> logic and is not part of URL class logic and the `setPort` like above.
> Next thing is that it again has all the getters and setters and is not
> immutable. Why can't it be a simple constructor with read-only properties,
> no getters, no setters? Maybe I miss some discussion about why here.
>
>
> The same goes for CurlException which looks like is an exception for
> handling some encoding of Url and not exactly to the Url properties itself.
>
> But with all that said, if the target audience is only a user of low lever
> `curl_*` functions rather than users of higher abstraction libraries like
> Guzzle or Httplug then, I guess I don't care that much.
> I'm only afraid that such a mix of responsibilities can lead to bad habits
> when it gets to the separation of concerns by developers who get used to it
> and won' see the problem as I do.
>
> Cheers,
> Michał Marcin Brzuchalski
>

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

[Pierrick Charron]

Hi all, and thanks Levi for your feedback,

If you look at the first thread (Discussion about new Curl URL API and
ext/curl improvements) you'll see that this was my first approach. I even
proposed to "OOPify" the actual CurlHandle & co objects with "simple"
methods like $ch->setOpt(). Anyone who reads the actual API can see this is
the actual "philosophy" of the extension. It was designed (on purpose or
not) as a thin wrapper over curl. But lets focus on URL API only !

With previous thread answers, I was under the impression that I really was
the only one liking the approach of following the cURL api as much as
possible and leaving the more high level API to things like Guzzle & co
(for example by adding an Implementation of PSR-7 UriInterface using this
API) since all the others parts of the API are done this way. I think it's
important to have this new Curl URL API in 8.2 since it fixes security
issues and that's of course not ideal but I would rather have an
implementation that would not be my first choice, than not having it at all.

What do you think ? I would love more people to give feedback on what they
are expecting, if they don't care if they prefer one approach or the other
and of course why ? I was thinking about doing a vote on this, but I'm not
sure it's a good idea. What do you all think ?

Regards,
Pierrick







Le jeu. 23 juin 2022, à 12 h 49, Levi Morrison 
a écrit :

> On Tue, Jun 21, 2022 at 10:38 PM Pierrick Charron 
> wrote:
> >
> > Hi,
> >
> > Following our discussions we had on the subject of the new Curl URL API,
> > and other curl improvements. I decided to only focus on adding the new
> Curl
> > URL API and put aside all other improvements. Here is the RFC that
> reflects
> > our current conversations.
> >
> > https://wiki.php.net/rfc/curl-url-api
> >
> > Feel free to give any feedback, concern or support :-)
> >
> > Regards,
> > Pierrick
>
> IMO, this should mirror the low-level curl url API very directly. The
> basis of my opinion is that we do not own libcurl; we are merely
> adapting it for use in PHP. We cannot anticipate changes in their
> design, nor do we have authority to do so if we feel something should
> change. Touching it as little as possible makes it easier to track
> upstream changes, etc.
>
> Based on that, I think the naming should be closer to libcurl.:
>   - CurlUrl::URL_ENCODE should be CurlUrl::URLENCODE
>   - CurlUrl::URL_DECODE should be CurlUrl::URLDECODE
>
> And so on, only differing if necessary because something is a reserved
> word. The API should be as exact as possible to what libcurl provides.
> The "helpers" getHost, getPassword, etc should be removed and should
> expose `curl_url_get` more directly.
>
> Of course, it should be object based instead of resource based, but that's
> it.
>
> A nicer API can be built on top of it, but I don't think that's the
> role this particular API should play.
>

[PHP-DEV] PHP 8.2.0alpha2 is available for testing

[Pierrick Charron]

PHP 8.2.0alpha2 has just been released and can be downloaded from:

https://downloads.php.net/~pierrick

or

https://qa.php.net/

or use the git tag: php-8.2.0alpha2

Windows binaries are available at: https://windows.php.net/qa/#php-8.2

Please test it carefully, and report any bugs to
https://github.com/php/php-src/issues

8.2.0alpha3 should be expected in 2 weeks, i.e. on July 7th 2022.

Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/33f3c8fff8ccaa80d57079cb849cc9c3

Thank you, and happy testing!

Regards,
Sergey Panteleev, Pierrick Charron & Ben Ramsey


php-8.2.0alpha2.tar.bz2
SHA256 hash:
b611eeff65d0b3e9182de230163e2345ecfd6fabb4e1e009dce099ba63a3f221
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmKx43URHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adx9RA//RArQCXUgZYDz0eRCK6E1cfVFRtwU6dLh
OU/j5lNbpAuMzDTcPzNd3akziu5dTrHenVE3QWHFNQruuqvmPwRSRxCwB/QymbXv
f4aembKwwcn/g9Aos+bSk1mPncIMv21eFOBWCwFFB3/hMJBl3eltAOzw2w5K17WV
XJwc7NwcwBwg7UW6qdsj4WXbIqzw+4Uef3jAciKuUOi/5v+z1YKqtVXF017qq9nr
LUwV+NMA9coGq1zhjUQ6r4NtLb4YMUB/2nGoEKpbGUmcm964yl9v4hI4MciYSqw5
DGSDmJb8oZK6Yy6vIFG7raa3nEWDFyVCv6zaqUMod9NJn9tGy6NDqooVSATvSeYP
nid4fN7OveypdX7iW/qr6AQbgbLG7jhvJoKmPHLRPFkSKZ7EgMoPoOgD1U42DdzW
rNYzO3GPxV6FHvXFcT8gKqXV7SsufsapsmgICY8bRkGIOSWGzgpf66ijRZ2aKkbx
/ynTkYg+LcY6ntMPxslZ2HeDS8lwmJciRWVGEfeSeORqJYO8sDmwp2jk+Ffgl+Xj
LE6wnYn3hjbQLKZ76e1qZPMFfibs1Ygj8Lp5vHxSA3tY3LYg2j8q5ObGBhd4Y77g
lotu0pNWpdmkkQGXudX0dmt0emR4NB0eEe0vUhGDHyoKqbkpx6ZKvEyxgV2p7Lpz
NoE8pgkw2LU=
=XOZ9
-END PGP SIGNATURE-


php-8.2.0alpha2.tar.gz
SHA256 hash:
92d8747a4380ae3e8020a1671a51173a051bbb3eb02af80962785dea342e5801
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmKx43YRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0adxsQQ/9E2JDKA5PcQVqswswItJuuQFLGjZl6sr6
HkeAdnyyzKlUlWZ9qmfWrs/1y/gaSw2MD6NVOZ7Fuu8awtd4kw26D36IQSoMzK2j
QBXn/c5Jn7q6QmZKlJINxr2eEAuOnoPrGBssjrVvA19cyJ3nS4fRQkTpWJU9abOc
IVgtI01Gmb9RmY+tTy8zFeBbrTzb149nFIuB4k3oN3jpy9aYV7AToF1TeH+MQ8ei
oRZ5LNmhVqNxIh+hxh/7htGX9DonJx2p2KyOXv+qd07yRbw67rc660XmA+uoxl0d
55kCTiba3u9JseoOzXQp7En3Y1Wu8NlbGgUAkUujC0qulqK5zSVJ8erm/9+r5LOC
KcpKFb6iaqTckyOBPRakfmDg6prOun1NG8Xvl5MS2YA/M22AOeVnvsfhQ8MyVZMO
qVhPPAw60ZF7bA2rnYUWnfntqFfySGZbfNHMp6XN7zb0esB9eCqVABfzcE4g3/+O
gbbrTqIkx2WoF79gmPkAgJRyQYbX0z4bBjlLazSKCRf2Vlftga5opWB2BGI0giKr
hnwuiSlrKDIAWxvMlPZCI+wYsrnkoa+n8inEya/KMtqzNweRqvJwyDYnRVIjhgPf
JBtaeclmPSJTnSN5TXEPZ6TPiynx+UtNHfteKARz6wIRECMxL06OQxEOAyCkmUQZ
ADBvDWLq00w=
=SSiL
-END PGP SIGNATURE-


php-8.2.0alpha2.tar.xz
SHA256 hash:
c7a44ae890c8e6dbb69ab8a6bc6385ddaae34a35af4d9acf87ffa00f5158c2d8
PGP signature:
-BEGIN PGP SIGNATURE-

iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmKx43YRHHBpZXJyaWNr
QHBocC5uZXQACgkQKGrx+Yl0ady+chAAmh6gavwz/5vXu2nLxmU7p1+kPNaPpHgT
j5Vo5WGSPk9FmEhHa2mQPaK47AblGHqm3fN4tFOgDFIgnWxBujE9NznyM1K0jV2T
tRsw9A7kzRjKTskPTW+y4KYXXy9S2o0wjRoQhZIr5LxmKK6PcZXnS25aSUCkQP5Z
VUpqSDp7uWqmRNQzarwoJ4cix0nQMhuzCRPCXf8N7bvnqOhu/0loRj1wgV4MOX+d
acuyBqD4tle1J49FGgV9uRtwYsGN/TxaeHc0xU79RLjX11b/GrlDcWzlbDAIMbZ5
g3EKrtlflN9kbWEPbt6VADtATPpWsILTOGp+9XsWoLSCs4/veNaGKkmxA4JxYPC0
pNyYeffkyj0x3OquIQ1H3SyVi06AaAv7E+eulTZdEII3xEzG0JtDHO4LiGwuX7cK
wDJw+wK24Uncsay1gbHiSaHvHaNHLw35pwfGsTfHLt9/Rw6zc6Qvn5rux4viDU+s
eieU/DN8A4qKTehL0/IwH+wJPZ5mWdUICNJGik2MRqPO6XveCSo1nXQIcM2hYq3P
uc5bPSvyylTyACpeZCiWx9FEV1+tgvL45MfLJrB0H3395zw4wqqS33fhTKhVJQ4f
BkdH1YQJeU/cTfchDPi+siiuEOHm2ANJejVHC9rL5COMk8wpIR3IzZr+XLue+nnG
mjgpDwFz9T8=
=y4P6
-END PGP SIGNATURE-

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

[Pierrick Charron]

HI Hans,

any particular reason CurlUrl::getPort() defaults to 0 rather than one of
> the valid options? (that being CurlUrl::DEFAULT_PORT
> and CurlUrl::NO_DEFAULT_PORT )
>

This is because the default is none of those 2 behaviours, If the  port
wasn't set it will return null, but if the port is the default port for the
scheme it will still return it.


makes it sound like these would return null: http://localhost:80/
> https://localhost:443/ ftps://localhost:22/
>
> Is that correct? I would imagine it returns null if the port isn't
> specified, rather than null if the port when specified matches the default
> port?
>
>
That's correct, if you use  CurlUrl::NO_DEFAULT_PORT. The behaviour you
were expecting is the default one ($flags = 0)

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

[Pierrick Charron]

Hi Derick,


>
> - The new CurlUrl class should probably be immutable from the start. It
> was my biggest mistake not to do that with DateTime.
>
>
Thanks for sharing your lessons learned. But I still see some use cases
where mutable objects are easier to use. From the experience you had with
DateTime, do you think that having `CurlUrl` being immutable and providing
a `MutableCurlUrl` would make sense ? I see some cases where you "navigate"
on a website using the same CurlHandle and just want to manipulate the
MutableCurlUrl handle to change urls.


> - What happens if the curl library available on the system does not have
> the features and functions that this new class relies on? I would expect
> the class to not be available either, but the RFC does not mention that.
>

Good point. As you expected, if the functions are not available in libcurl,
the class will not be available. Same thing for each constant/feature. The
extension will "adapt" to the curl version. I will add this to the RFC.

Pierrick

[PHP-DEV] [RFC] [Under Discussion] New Curl URL API

[Pierrick Charron]

Hi,

Following our discussions we had on the subject of the new Curl URL API,
and other curl improvements. I decided to only focus on adding the new Curl
URL API and put aside all other improvements. Here is the RFC that reflects
our current conversations.

https://wiki.php.net/rfc/curl-url-api

Feel free to give any feedback, concern or support :-)

Regards,
Pierrick

Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements

[Pierrick Charron]

>
>
> I haven't read back through the thread, but my impression was that *for
> the curl URL facility specifically* the opposite was the case: a simple
> object with no procedural equivalent would be everyone's preference.
> CurlFile provides enough of a precedent for adding that IMO.
>

+1


>
> Either way, we have to agree on some naming details, so I've left some
> comments on the PR.
>
>
Your suggested names were good, so I used them except for
`NON_SUPPORT_SCHEME` that I replaced with `ALLOW_UNSUPPORTED_SCHEME`.


> (By the way, the PR you linked is to merge into your own fork's master,
> not the actual central php-src repo. Not sure if that was deliberate.)
>

I didn't do it intentionally. Sorry about that.

Regards
Pierrick

[PHP-DEV] [PHP 8.2] 30 days before feature freeze

[Pierrick Charron]

Hi internal,

This is a friendly reminder from your RMs that the PHP 8.2 feature-freeze
is in a month now [1] and time flies. If you plan to submit a RFC you have
until July 5th to open it for vote so that it can be closed on time.

Regards,
Sergey, Pierrick and Ben

[1] https://wiki.php.net/todo/php82

Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements

[Pierrick Charron]

Rowan, all,

Thanks again for your comments. PHP8.2 is going to be feature freeze in
exactly one month now and as the currently proposed improvements have not
received any interest (and that's OK), I will put those aside for the
moment and come back with a new approach that I hope will be better for the
future release (8.3 ?)

However, about the new Curl URL API, I think it's still time to finalize
the discussions and include it in the 8.2 release as it allows us to solve
some potential security issues.

What do you think ? Do you see any interest in adding the new CurlUrl class
in PHP8.2 ? Again currently proposed implementation can be found here [1]
and is waiting for your new comments.

Pierrick

[1]
https://github.com/adoy/php-src/pull/1/files#diff-5bd329a70f563b5b6eded3b710514a4fac605329087a7bd118e40f80b9fc8ee3


Le dim. 19 juin 2022, à 09 h 55, Rowan Tommins  a
écrit :

> On 19 June 2022 03:53:17 BST, Pierrick Charron  wrote:
> >
> >I hope you don't mind, I took some of your code from your "Enable
> >strict_types checking for curl_setopt()" pull request [1] to do some test
> >on introducing this but only on the OOP API. It's working very well [2].
> >Can I know why this PR was closed ? Any issues ? Or was it more because it
> >was too much of a change for the procedural API ?
>
> While a few type errors there might be useful, it still feels a bit like
> polishing a turd.
>
> I count about 180 different options that can be passed to curl_setopt.
> Some of them are used by nearly every user of PHP, and some are for very
> obscure niche uses. Many of them are useless on their own, and exist only
> to tweak the behaviour of some other option, or need to be used in groups
> like usernames and passwords. Others have unintuitive and unhelpful
> defaults, that need to be overridden with a different option. The manual
> page has long topped the league table for user comments, currently standing
> at 102. It is simply not a practical design for what most users of PHP need.
>
> I think one way out of this mess is to start grouping options together,
> and providing specific methods to set them, with named, type-safe
> parameters. For instance, CurlHandle::setProxyOptions(string $url, ?string
> $authUserName, ?string $authPassword, ...) and so on.
>
> If the long lists of parameters still feel a bit messy, we could go a step
> further and make objects for building sets of options, with methods taking
> short lists of genuinely dependent options, e.g.
> CurlProxyOptions::setAuth(string $userName, string $password) and
> CurlProxyOptions::disableAuth()
>
> Some of the options should be rethought in the process to make more sense
> to PHP's common usage, rather than libcurl's. As just one example, enabling
> CURLOPT_VERBOSE sends some debug information to stderr, but on a web server
> that is normally a log file where it will be mixed in with other
> information. To capture it instead you need to also set CURLOPT_STDERR,
> which requires an open file handle. What most users *actually* want is for
> that information to be available to them as a string after the request is
> executed.
>
> Another thing that might be useful is some new factory methods that set
> sensible defaults, like CurlHandle::createForHttp(string|CurlUrl $url,
> string $method)
>
> If we can build these things on top of the existing CurlHandle, we can
> release a few things first, and progressively add features. Rather than
> having to decide which extension to use, users will still have access to
> curl_setopt for things there isn't a nicer interface for yet. We can even
> leave it in place as something like CurlHandle::setRawOption for when users
> want fine control of the library, or some really obscure setting.
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements

[Pierrick Charron]

Hi Sara


> This is so bizarre, I *know* I wrote an OOPified cURL extension some years
> ago (called it curli), and now I can't find it anywhere.  What universe am
> I even in?
>

I don't know but if you pass through the parallel universe where Curli is,
I'm interested.


>
> Anyway, +1 on making a whole new OOPified cURL implementation.$ch =
> (new CurlHandle($uri))->setOpt(Curl::OPT_METHOD, 'post')->perform();
> Let it throw exceptions, do proper type checks, all the goodness.  Let the
> procedural APIs behave differently than the object methods and that's okay.
>
> cURL is a foundational extension in PHP and I respect the choices that
> were made in its API design, but it's 2022, and we deserve a better
> ext/curl.
>

I hope you don't mind, I took some of your code from your "Enable
strict_types checking for curl_setopt()" pull request [1] to do some test
on introducing this but only on the OOP API. It's working very well [2].
Can I know why this PR was closed ? Any issues ? Or was it more because it
was too much of a change for the procedural API ?

Thanks
Pierrick

[1] https://github.com/php/php-src/pull/2495
[2] https://github.com/adoy/php-src/pull/2

Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements

[Pierrick Charron]

Hi Rowan, all,

Thanks for your responses and comments.


> I think it's perfectly reasonable for CurlUrl to be designed the same way,
> regardless of what else we do with the extension.
>

As suggested by most of you, I created a new version of the proposed new
URL API with a friendlier interface [1]. A quick descriptions of the
changes I made :
- The curl_url_* procedural API was removed
- The CurlUrl::set() and ::get() methods with the CURLUPART_ constants were
replaced by more explicit setters and getters (ex: setHost() and getHost()).
- All the CURLU_* constants are now CurlUrl class constants (ex:
CURLU_GUESS_SCHEME => CurlUrl::GUESS_SCHEME)
- All the CURLUE_* constants are now CurlUrlException class constants (ex:
CURLUE_MALFORMED_INPUT => CurlUrlException::MALFORMED_INPUT)

Does it look more like what you were expecting ? Any other improvements
that should be made ?

This feels like a very small gain, since users can already type "curl_" and
> get a list of all curl functions. It also has real costs: users may be
> confused why there are two ways of writing the same thing; and it sets the
> precedent that methods on CurlHandle should mirror curl_* functions, even
> though we know those have terrible usability.
>

This is not the only change that I would like to introduce with a new OO
API. One other change that I would like to introduce is a better type
checking of `CurlHandle::setOpt()` when declaring strict_types to 1 (I know
Sara once opened a PR about this [2]). The current signature of the
procedural API is `curl_setopt(CurlHandle $handle, int $option, mixed
$value): bool`. The 3rd argument being mixed never throws any TypeError,
and adding this to the current procedural API would be a breaking change.
If we add a new OOP API this kind of change is possible and we can improve
the error message like : "Argument 2 passed to CurlHandle::setOpt() for
option CURLOPT_BUFFERSIZE must be of type int, string given"

However, knowing that the feature freeze for 8.2 is in a month, I will put
more emphasis on the Curl URL API than on a new OO API for existing Curl
API.

Thanks again for your feedback

Pierrick

[1] https://github.com/adoy/php-src/pull/1/files
[2] https://github.com/php/php-src/pull/2495

Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements

[Pierrick Charron]

Hi Lynn,

You have to be careful, even though most developers associate curl with an
http client and only use this feature, it's only part of what it is. It's
a multiprotocol file transfer library that supports DICT, FILE, FTP, FTPS,
GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S,
RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP.

Again I'm not against a new extension that deals nicely with HTTP and has a
super nice intuitive OOP API. But for me that's just not the curl
extension. That would be a different project like ext/http.

Pierrick

Le ven. 17 juin 2022, à 04 h 27, Lynn  a écrit :

> Good timezone!
>
> On Thu, Jun 16, 2022 at 11:44 PM Pierrick Charron 
> wrote:
>
>> About making a "Good OOP API", of course the goal is to make a *Good* OOP
>> API. But there are things to take into consideration. The proposal here is
>> yes to expose the new Curl URL API which is quite small, but also to
>> modify
>> the existing curl API to make it a little bit more digest for developers.
>> Good or bad the existing ext/curl is here and will continue to exist for
>> quite some time. It was designed (maybe on purpose or not) to be a low
>> level API with tons [1] of low level features, and it was clearly designed
>> as a thin wrapper/bridge over libcurl. I mean the fact is currently each
>> constant is the exact same one as in libcurl, and each function is a
>> wrapper over the exact same function in libcurl. Is it OK to have one part
>> that is a thin wrapper and another part that is a "remodeling" of the API
>> ?
>> (This is not a rhetorical question, I really ask myself the question).
>>
>
> I'm not a C developer, and the only other place I've ever used cURL is on
> the command line. I honestly care very little for it resembling whatever
> the C library is, as C is a different language with no OOP. The procedural
> API for cURL is really annoying to deal with, and I think it would be worth
> designing an OOP counterpart. I think most of this would go into a new
> design for setting options among things, as a list of constants with
> possible values is one of the worst ways to have to configure something in
> my opinion. I know that both the Symfony Http Client and Guzzle are popular
> libraries, perhaps design wise they could serve as an inspiration?
>
> I'm personally not too experienced with cURL nor the level of details that
> go into http libraries, but I do see this as an opportunity to make a
> really good implementation from scratch. In my opinion it's worth spending
> some time on this.
>
> Larry said:
>
> Like most of the responders so far, I would say skip the procedural API,
>> just go OOP and be done with it.
>>
>
> I'm okay implementing one last feature in the procedural API if it's
> really desired to have this functionality, especially if this is beneficial
> for security and reduces bugs. The reason being is that even if we have the
> best possible OOP library for cURL, every single procedural API would
> benefit from this change without having to completely rewrite their
> implementation, which will be a problem if the OOP interface isn't just a
> 1:1 copy into object form. That said, we should avoid having: cURL
> procedural + cURL procedural in objects + cURL OOP. Having 2 different
> object based libraries to do the same thing PHP is confusing and will just
> end up in way too many Stack Overflow questions.
>
> Perhaps it is best to split this into 2 separate RFCs?
>
> Regards,
> Lynn
>

Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements

[Pierrick Charron]

Thanks for taking the time to answer and give feedback, that's really
appreciated.

Firstly, about the procedural API, if everyone agrees that we should not
create it (and it looks like it) I will definitely not go against it. This
was just to make it consistent with the current ext/curl api. Reading the
thread about IntlDatePatternGenerator (thanks Mel), it's clear that the
procedural API for the new API will be discarded.

About making a "Good OOP API", of course the goal is to make a *Good* OOP
API. But there are things to take into consideration. The proposal here is
yes to expose the new Curl URL API which is quite small, but also to modify
the existing curl API to make it a little bit more digest for developers.
Good or bad the existing ext/curl is here and will continue to exist for
quite some time. It was designed (maybe on purpose or not) to be a low
level API with tons [1] of low level features, and it was clearly designed
as a thin wrapper/bridge over libcurl. I mean the fact is currently each
constant is the exact same one as in libcurl, and each function is a
wrapper over the exact same function in libcurl. Is it OK to have one part
that is a thin wrapper and another part that is a "remodeling" of the API ?
(This is not a rhetorical question, I really ask myself the question).

Yes we could create a completely new high level API using curl underneath
but I think that if this is what we want, we should create a brand new
extension and start from scratch and design it as a nice High level API
from the start. But that's clearly not what I'm pretending to do.

We could also keep the existing API as is and not improve it living only
with the procedural API, but I think that with minimal effort, we could get
some small (but still) benefits. Yes, CurlHandle for example would just be
a wrapper on the procedural API that happens to use `->` and throw
exceptions instead of returning null/false,  but one of the gains would be
to help developers with autocomplete to find methods they can call on the
handle.

I'm sorry if the fact that this proposal includes two different subjects is
confusing but I think that how we want to deal with the current API will
have an effect on how we want to implement the new one and keep the thing
consistent.

You only talked about the new CurlUrl API in your previous mail, but I'm
curious what you would do with the existing API ?

Pierrick

[1] https://github.com/php/php-src/blob/master/ext/curl/interface.c#L382

Le jeu. 16 juin 2022, à 15 h 48, Larry Garfield  a
écrit :

> On Thu, Jun 16, 2022, at 2:10 AM, Pierrick Charron wrote:
> > Hi internals,
> >
> > Since its version 6.62.0 [1], libcurl features a brand new URL API [2]
> that
> > can be used to parse and generate URLs, using libcurl’s own parser. One
> of
> > the goals of this API is to tighten a problematic vulnerable area for
> > applications where the URL parser library would believe one thing and
> > libcurl another. This could and has sometimes led to security problems
> [3].
> > The new API is handled base and composed of 5 new functions [4] (and one
> > more since 7.80.0 to get more verbose information upon error).
> >
> > I started to work on an implementation [5] to expose this API to PHP
> > userland in the curl extension so that PHP users can benefit from it. My
> > first reflex was to stay consistent on how the extension is currently
> > working and do a one to one mapping of the new curl functions. I got
> > feedback from both Ilija and Christoph saying that the API is, I quote,
> "a
> > bit clunky" which I can't disagree with.
> >
> > For a long time, ext/curl worked with handles as "curl resources" and
> > functions mapped to the libcurl functions, but since PHP8.0 "curl
> > resources" were converted to opaque classes with no methods. So my main
> > goal here is to come up with a solution for the new Curl URL API, but
> maybe
> > also to be consistent, make some changes to existing curl classes like
> > `CurlHandle` to add methods and improve the current state of the
> extension.
> >
> > Here is the solution I would propose :
> > - First of course keep all the current ext/curl functions as is not to
> > break any compatibility (Seems obvious but just to be sure everybody is
> on
> > the same page).
> > - For consistency expose the new Curl URL API as functions mapped one to
> > one to libcurl functions :
> >
> > function curl_url(?string $url = null): CurlUrl|false {}
> > function curl_url_set(CurlUrl $url, int $part, string $content, int
> $flags
> > = 0): bool {}
> > function curl_url_get(CurlUrl $url, int $part, int $flags = 0):
> > string|false {}
> > function curl_url_errno(CurlUrl $url): 

[PHP-DEV] Discussion about new Curl URL API and ext/curl improvements

[Pierrick Charron]

Hi internals,

Since its version 6.62.0 [1], libcurl features a brand new URL API [2] that
can be used to parse and generate URLs, using libcurl’s own parser. One of
the goals of this API is to tighten a problematic vulnerable area for
applications where the URL parser library would believe one thing and
libcurl another. This could and has sometimes led to security problems [3].
The new API is handled base and composed of 5 new functions [4] (and one
more since 7.80.0 to get more verbose information upon error).

I started to work on an implementation [5] to expose this API to PHP
userland in the curl extension so that PHP users can benefit from it. My
first reflex was to stay consistent on how the extension is currently
working and do a one to one mapping of the new curl functions. I got
feedback from both Ilija and Christoph saying that the API is, I quote, "a
bit clunky" which I can't disagree with.

For a long time, ext/curl worked with handles as "curl resources" and
functions mapped to the libcurl functions, but since PHP8.0 "curl
resources" were converted to opaque classes with no methods. So my main
goal here is to come up with a solution for the new Curl URL API, but maybe
also to be consistent, make some changes to existing curl classes like
`CurlHandle` to add methods and improve the current state of the extension.

Here is the solution I would propose :
- First of course keep all the current ext/curl functions as is not to
break any compatibility (Seems obvious but just to be sure everybody is on
the same page).
- For consistency expose the new Curl URL API as functions mapped one to
one to libcurl functions :

function curl_url(?string $url = null): CurlUrl|false {}
function curl_url_set(CurlUrl $url, int $part, string $content, int $flags
= 0): bool {}
function curl_url_get(CurlUrl $url, int $part, int $flags = 0):
string|false {}
function curl_url_errno(CurlUrl $url): int {}
function curl_url_strerror(int $error_code): ?string {}

- Add methods to the CurlUrl object to make it less opaque and expose an
object oriented style API. I would keep it minimal and let userlanAd API
provide higher level APIs as guzzle for example. (You can see the current
implementation [5])

final class CurlUrl implements Stringable
{
public function __construct(?string $url = null) {}
public function get(int $part, int $flags = 0): string {}
public function set(int $part, string $content, int $flags = 0): void {}
public function getErrno(): int {}
public function __toString(): string {}
public function __clone() {}
}

- It would also be nice to add this object oriented API for existing
CurlHandle, CurlMultiHandle and CurlShareHandle classes. For example the
CurlHandle class would look like that (First implementation [6])

final class CurlHandle
{
public function __construct(?string $url = null) {}
public function setOpt(int $option, mixed $value): bool {}
public function getInfo(?int $option = null): mixed {}
public function exec(): string|bool {}
public function escape(string $string): string|false {}
public function unescape(string $string): string|false {}
public function pause(int $flags): int {}
public function getErrno(): int {}
public function reset(): void;
public function setOptArray(array $options): bool {}
public function upkeep(): bool {}
public function __clone() {}
}

As of right now I still have some unanswered questions like how should we
handle errors on the new CurlUrl API ?
- Throw `CurlUrlException` on both the procedural and object oriented style
API (that's how current implementation works [5])
- Throw `CurlUrlException` with the oriented style API, but return for
example boolean/null on errors when user uses the procedural API ?
- Always return null/booleans using both object oriented API and
procedural API ?

The same question applies if we add a new object oriented style API on
existing classes. Current functions MUST stay unchanged but should we throw
`CurlException` when the user uses the object oriented style API ? (That's
what I would do) Or should we return the same result from OO and procedural
API ? Should we make the new CurlApi consistent with that ?

What are your thoughts about all this ? Any feedback on any of those
subjects are more than welcome.

Pierrick

[1]
https://daniel.haxhttps://github.com/adoy/php-src/tree/curl-object-apix.se/blog/2018/10/31/curl-7-62-0-moar-stuff/

[2] https://daniel.haxx.se/blog/2018/09/09/libcurl-gets-a-url-api/
[3]
https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf
[4] https://github.com/curl/curl/blob/master/include/curl/urlapi.h
[5] https://github.com/php/php-src/pull/8770
[6] https://github.com/adoy/php-src/tree/curl-object-api

Re: [PHP-DEV] Re: [8.2] Release Manager Election

[Pierrick Charron]

Thanks Rémi.

I saw You found it, but as you probably noticed I'm not a big user of
twitter. But I'll probably use it more now to promote new releases.

Le jeu. 19 mai 2022, à 04 h 28, Remi Collet  a écrit :

> Le 18/05/2022 à 20:45, Ben Ramsey a écrit :
> >
> > Our 8.2 “rookie” release managers are:
> >
> > * Sergey Panteleev
> > * Pierrick Charron
>
>
> Congrats to Sergei and Pierrick!
>
>
> Do you have a twitter account ?
>
>
> Cheers,
> Remi
>

Re: [PHP-DEV] Re: [8.2] Release Manager Election

[Pierrick Charron]

Thanks a lot everyone for your trust and congratulations to Sergey and Ben.
I'm looking forward to work with you both.

Pierrick

Le mer. 18 mai 2022, à 14 h 58, Evan Sims via internals <
internals@lists.php.net> a écrit :

> Congratulations Sergei and Pierrick!
>
> Cheers,
> Evan
>
> On May 18, 2022, Ben Ramsey  wrote:
> > > On May 11, 2022, at 09:51, Ben Ramsey  wrote:
> > >
> > > Happy middle of the week, everyone!
> > >
> > > We’ve had another great turn-out for PHP Release Manager selection
> > this year.
> > >
> > > In the role of “Veteran” release manager, Ben Ramsey[0] (that’s me!)
> > has volunteered to mentor two rookies, so there will be two seats up
> > for grabs. As I mentioned in an earlier message, Joe and I discussed
> > that it might be a good practice to have one of the rookie RMs from
> > the current release serve as the veteran for the next release. In this
> > way, any new advances or changes to the process will be carried
> > forward to the “next generation” much more smoothly. So, we’re going
> > to give that a try and see how well it works.
> > >
> > > For those two rookie seats, we’ve got seven eager candidates for
> > your consideration [1-7]. Some of these included a statement about
> > their background in their initial email volunteering for the role, the
> > rest I encourage to reply to this thread providing some background on
> > why they’ll be awesome.
> > >
> > > Voting is now open on https://wiki.php.net/todo/php82 using “Single
> > Transferrable Vote” (STV). Those who participated in prior elections
> > will recognize the format; for the rest, the TL;DR is that it allows
> > each voter to state their preference order by voting multiple times.
> > There are seven polls on the wiki for your seven preferences, in
> > descending order. Using some math that I’ll leave to Wikipedia[8] to
> > explain, we’ll start with the 1st preference and gradually remove
> > candidates with the fewest votes, transferring votes that had
> > previously gone to them to their voter’s 2nd preference, and so on.
> > Once two candidates have a quorum (Droop quota), those will be
> > officially selected as our RMs. Derick Rethans has volunteered to
> > proctor the tabulation of the votes since he still has scripts from
> > last year.
> > >
> > > As you consider each candidate, please bear in mind that this is a
> > 3.5 year commitment and is a position of trust.
> > >
> > > Thank you in advance for your consideration.
> > >
> > > Your 8.1 Release Managers,
> > > Ben Ramsey, Patrick Allaert, & Joe Watkins
> > >
> > > Vote Opens: 11 May 2022
> > > Vote Closes: 18 May 2022
> > >
> > > Refs:
> > > 0 - Ben Ramsey: https://news-web.php.net/php.internals/117664
> > > 1 - Sergey Panteleev: https://news-web.php.net/php.internals/117596
> > > 2 - Evan Sims: https://news-web.php.net/php.internals/117621
> > > 3 - Aaron Junker: https://news-web.php.net/php.internals/117623
> > > 4 - Calvin Buckley: https://news-web.php.net/php.internals/117627
> > > 5 - Eric Mann: https://news-web.php.net/php.internals/117629
> > > 6 - Pierrick Charron: https://news-web.php.net/php.internals/117650
> > > 7 - Saif Eddin Gmati: https://news-web.php.net/php.internals/117702
> > > 8 - https://en.wikipedia.org/wiki/Single_transferable_vote
> > >
> >
> > The polls have closed, and Derick’s scripts have tallied the
> > votes.[^1]
> >
> > Our 8.2 “rookie” release managers are:
> >
> > * Sergey Panteleev
> > * Pierrick Charron
> >
> > Congratulations!
> >
> > Thank you to all the candidates! I hope you’ll consider putting in
> > your name for future release manager elections, and as always, PHP
> > needs your help in many other ways, so please continue to volunteer
> > and help out.
> >
> > Sergey and Pierrick, I’ll be in touch with you soon to get you started
> > on the first alpha release of 8.2, due out on 9 June.
> >
> > Cheers,
> > Ben
> >
> >
> > [^1]: https://gist.github.com/derickr/f13396ce8d9c0ed7bc84a23ba15d5406
>

Re: [PHP-DEV] PHP 8.2 Release Manager Selection

[Pierrick Charron]

Hi,

I would also like to present myself as a Rookie RM for PHP8.2

For those of you who don't know me, my name is Pierrick. I am French (that
explains my grammar mistakes) and have been living in Montreal, Canada for
15 years now and have been working with PHP since then.
I made my first contribution to the PHP Project in 2009 by submitting a
small patch. Since then I have touched multiple parts of the PHP project. I
patched a few bugs, contributed to the french documentation translation,
wrote/maintained some pecl extensions, maintained ext/curl from 2010 to
2016. I also submitted fews RFCs with their patches, some were approved and
others rejected. I'm not a C guru but have basic knowledge of it (I never
worked professionally with it). I also have some knowledge of PHP
internals, but I did not touch the code base for quite some time. I work
with git every day and am very comfortable with it.

I would like to apply as a Rookie RM. I never had the opportunity to do
release management on a project of this scale, but I'm motivated to learn.

Thanks for considering me.

Pierrick

Le mer. 27 avr. 2022, à 01 h 15, Joe Watkins  a écrit :

> Hi all,
>
> Applications are open for a week.
>
> Two people will be chosen by election and a veteran will help them.
>
> If no other veteran comes forward I will continue in that role for 8.2.
>
> Cheers
> Joe
>
> On Tue, 26 Apr 2022, 21:21 Eric Mann via internals, <
> internals@lists.php.net>
> wrote:
>
> > I'm new to this mailing list as I'd previously (and very mistakenly)
> > assumed it was meant for existing contributors. So I've always consumed
> > conversations via web-based aggregators rather than directly.
> >
> > My mistake.
> >
> > That being said, I am very interested in being a part of this release.
> > I've been using PHP since ~2005 and cut my teeth on PHP4. Since then,
> > I've covered everything from Fortran to VB.net and C# to Ruby to Python
> > to Golang. Today I write a mix of Python and PHP primarily (with a
> > smattering of Go and a curiosity about Rust). I'm not a C guru, but in
> > previous roles worked with several of them and can follow my way around
> > a C codebase. I've frequently gone spelunking through PHP's system to
> > help document various methods or interfaces exposed by the standard
> > library as well.
> >
> > I am in no way a veteran PHP RM, but I am a fairly experienced RM with
> > private codebases. I live and breathe in Git, love automation, and have
> > been accused of more than a passing fancy in security as well. Somewhere
> > along the line I managed to coax php[architect] into publishing my book
> > on the OWASP Top Ten, and they still put up with my monthly security
> > column as well.
> >
> > In other words, I'd love to be a part of this and am more than happy to
> > answer any and all questions y'all want to throw my way.
> >
> > ~Eric Mann
> >
> > On 4/26/22 11:27 PM, Sergey Panteleev wrote:
> > > From: *Sergey Panteleev* 
> > > Date: Tue, Apr 26, 2022 at 11:27 AM
> > > Subject: [PHP-DEV] PHP 8.2 Release Manager Selection
> > > To: Christoph M. Becker , PHP internals
> > > 
> > >
> > >
> > > Hey Christoph,
> > >
> > > Do we choose one rookie for this release or two (as for 8.1)?
> > >
> > > Also, maybe define some kind of deadline for submitting applications
> > > and the voting phase, thoughts?
> > >
> > > —
> > > wbr,
> > > Sergey Panteleev
> > >
> > --
> > Security Principles for PHP Applications
> >  >
> > *Eric Mann
> > * Tekton
> > *PGP:*0x63F15A9B715376CA 
> > *P:*503.925.6266
> > *E:*e...@eamann.com
> > eamann.com 
> > ttmm.io 
> > Twitter icon  LinkedIn icon
> > 
> >
>

[PHP-DEV] Best way to fix #71929 curl_getinfo($ch, CURLINFO_CERTINFO)

[Pierrick Charron]

Hi,

I'm currently looking at bug #71929 and i'm wondering what is the best way
to fix it. Basically the bug is that currently ext/curl tries to parse the
"Subject" and "Issuer" returned by lib/curl to return this information as a
PHP array.

Here is the actual output :
array (
'Subject' => array (
  'C ' => ' US, ST = New Jersey, L = Jersey City, O = The USERTRUST
Network, CN = USERTrust RSA Certification Authority',
),
'Issuer' => array (
  'C ' => ' SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN
= AddTrust External CA Root',
),
/* ... */
)

I think the real output that curl_getinfo($ch, CURLINFO_CERTINFO) should
return is something like

array (
'Subject' => 'C = US, ST = New Jersey, L = Jersey City, O = The
USERTRUST Network, CN = USERTrust RSA Certification Authority',
'Issuer' => 'C = SE, O = AddTrust AB, OU = AddTrust External TTP
Network, CN = AddTrust External CA Root',
 /* ... */
)

https://github.com/adoy/php-src/commit/7a7fbd51e1d51fed380a6f391fe7b282b55224d7

Since curl returns this two informations as a string and nothing in the
documentation enforce the way this string is structured.
Problem is that this fix might break things. I tried to search on code
who's using this variable and did not find any.

Do you think I should push this change and then we could add something in
the release not to tell users that this was changed ?
On which versions should I fix this problem ?

Thanks for your feedback

Pierrick

[PHP-DEV] [RFC][Accepted] Add curl_multi_errno(), curl_share_errno() and curl_share_strerror()

[Pierrick Charron]

Hi,

The vote on the RFC https://wiki.php.net/rfc/new-curl-error-functions#vote is
now closed. The RFC was accepted with 23 "Yes" and 0 "No". I'll merge the
patch in the master branch this week-end.

Thanks to anybody who contributed to this RFC by voting.
Pierrick

[PHP-DEV] [VOTE] Add curl_multi_errno(), curl_share_errno() and curl_share_strerror()

[Pierrick Charron]

Hi Internals,

Since I got no feedback on the RFC about the addition of those 3 functions
and that this is not a big change I decided to open the vote.

https://wiki.php.net/rfc/new-curl-error-functions

Feedback and questions are as always welcome !

[PHP-DEV] [RFC][Accepted] Catching Multiple Exception Types

[Pierrick Charron]

Hi,

The vote on the RFC https://wiki.php.net/rfc/multiple-catch#vote is now
closed. The RFC was accepted with 40 "Yes" and 6 "No". I'll merge the patch
in the master branch today.

Thanks to anybody who contributed to this RFC by voting or giving us
feedback.
Bronisław and Pierrick

[PHP-DEV] [RFC][Discussion] Add curl_multi_errno(), curl_share_errno() and curl_share_strerror()

[Pierrick Charron]

Hi Internals,

I would like to introduce 3 new functions to ext/curl

- curl_multi_errno()
- curl_share_errno()
- curl_share_strerror()

With those 3 functions added, it will now be possible to get any error that
curl detect on any of the curl resource types and the error message
associated to it.

https://wiki.php.net/rfc/new-curl-error-functions

Feedback and questions are welcome.

Pierrick

Re: [PHP-DEV] Re: ext/curl update

[Pierrick Charron]

Hi Anatol,

I created a new patch from the one first published but this time this one
target 7.0 and only expose new constants to that do not require any logic
on the extension side.
These constants are just exposed if they are available in the version
installed and are bridge in the curl_setop function.

If that's OK I'll commit this on 7.0 and merge it also on master. Then I'll
work on adding new things that require logic and clean those for 7.1 and
add tests if possible.

Regards
Pierrick

On 27 April 2016 at 12:55, Anatol Belski <anatol@belski.net> wrote:

>
>
> > -Original Message-
> > From: pierr...@webstart.fr [mailto:pierr...@webstart.fr] On Behalf Of
> Pierrick
> > Charron
> > Sent: Wednesday, April 27, 2016 6:20 PM
> > To: Anatol Belski <anatol@belski.net>
> > Cc: Davey Shafik <da...@php.net>; PHP internals <internals@lists.php.net
> >;
> > paj...@php.net
> > Subject: Re: [PHP-DEV] Re: ext/curl update
> >
> > Yep I'll check if I can add some test that could be easy to implement
> using
> > curl_easy_getinfo or using the php local server. Otherwise not sure we
> could
> > easily compile PHP with all those libcurl versions...
> >
> >
> > On 27 April 2016 at 11:37, Anatol Belski <anatol@belski.net
> > <mailto:anatol@belski.net> > wrote:
> >
> >
> >   Hi,
> >
> >   > -Original Message-
> >   > From: pierr...@webstart.fr <mailto:pierr...@webstart.fr>
> > [mailto:pierr...@webstart.fr <mailto:pierr...@webstart.fr> ] On Behalf
> Of
> > Pierrick
> >   > Charron
> >   > Sent: Wednesday, April 27, 2016 2:20 PM
> >   > To: Anatol Belski <anatol@belski.net
> > <mailto:anatol@belski.net> >
> >   > Cc: Davey Shafik <da...@php.net <mailto:da...@php.net> >; PHP
> > internals <internals@lists.php.net <mailto:internals@lists.php.net> >;
> >   > paj...@php.net <mailto:paj...@php.net>
> >   > Subject: Re: [PHP-DEV] Re: ext/curl update
> >   >
> >   > I agree, but I don't really now how I could test those things
> since they
> > almost all
> >   > of the time only affect how libcurl will handle the
> request/cache and
> > we have no
> >   > way to retrieve options like curl_easy_getopt or something
> similar.
> >   >
> >   > On 27 April 2016 at 02:46, Anatol Belski <anatol@belski.net
> > <mailto:anatol@belski.net>
> >   > <mailto:anatol@belski.net <mailto:anatol@belski.net> > >
> > wrote:
> >   >
> >   >
> >   >   Hi,
> >       >
> >   >   > -Original Message-
> >   >   > From: m...@daveyshafik.com <mailto:m...@daveyshafik.com>
> > <mailto:m...@daveyshafik.com <mailto:m...@daveyshafik.com> >
> >   > [mailto:m...@daveyshafik.com <mailto:m...@daveyshafik.com>
> > <mailto:m...@daveyshafik.com <mailto:m...@daveyshafik.com> > ] On Behalf Of
> >   > Davey
> >   >   > Shafik
> >   >   > Sent: Sunday, April 24, 2016 2:25 AM
> >   >   > To: Pierrick Charron <pierr...@adoy.net
> > <mailto:pierr...@adoy.net>  <mailto:pierr...@adoy.net
> > <mailto:pierr...@adoy.net> > >
> >   >   > Cc: PHP internals <internals@lists.php.net
> > <mailto:internals@lists.php.net>
> >
> >   > <mailto:internals@lists.php.net <mailto:internals@lists.php.net>
> > >;
> > paj...@php.net <mailto:paj...@php.net>  <mailto:paj...@php.net
> > <mailto:paj...@php.net> >
> >   >   > Subject: [PHP-DEV] Re: ext/curl update
> >   >   >
> >   >   > Hi Pierrick,
> >   >   >
> >   >   > This should be in master for 7.1, alongside my RFC'ed
> patch for
> > server
> >   > push
> >   >   > support.
> >   >   >
> >   >   > You emailed me directly about the aforementioned patch
> so I'll
> > just
> >   > respond
> >   >   > here as it's relevant:
> >   >   >
> >   >   > The patch should hit in 7.1 but it has been requested
> that tests be
> >   > added — and
> >   >   > we can't add tests with a server push supporting HTTP/2
> server
> > against

Re: [PHP-DEV] Re: ext/curl update

[Pierrick Charron]

Sorry for the 2 mails but I forgot to give you the URL :

https://github.com/php/php-src/pull/1890/files

On 27 April 2016 at 19:14, Pierrick Charron <pierr...@adoy.net> wrote:

> Hi Anatol,
>
> I created a new patch from the one first published but this time this one
> target 7.0 and only expose new constants to that do not require any logic
> on the extension side.
> These constants are just exposed if they are available in the version
> installed and are bridge in the curl_setop function.
>
> If that's OK I'll commit this on 7.0 and merge it also on master. Then
> I'll work on adding new things that require logic and clean those for 7.1
> and add tests if possible.
>
> Regards
> Pierrick
>
> On 27 April 2016 at 12:55, Anatol Belski <anatol@belski.net> wrote:
>
>>
>>
>> > -Original Message-
>> > From: pierr...@webstart.fr [mailto:pierr...@webstart.fr] On Behalf Of
>> Pierrick
>> > Charron
>> > Sent: Wednesday, April 27, 2016 6:20 PM
>> > To: Anatol Belski <anatol@belski.net>
>> > Cc: Davey Shafik <da...@php.net>; PHP internals <
>> internals@lists.php.net>;
>> > paj...@php.net
>> > Subject: Re: [PHP-DEV] Re: ext/curl update
>> >
>> > Yep I'll check if I can add some test that could be easy to implement
>> using
>> > curl_easy_getinfo or using the php local server. Otherwise not sure we
>> could
>> > easily compile PHP with all those libcurl versions...
>> >
>> >
>> > On 27 April 2016 at 11:37, Anatol Belski <anatol@belski.net
>> > <mailto:anatol@belski.net> > wrote:
>> >
>> >
>> >   Hi,
>> >
>> >   > -Original Message-
>> >   > From: pierr...@webstart.fr <mailto:pierr...@webstart.fr>
>> > [mailto:pierr...@webstart.fr <mailto:pierr...@webstart.fr> ] On Behalf
>> Of
>> > Pierrick
>> >   > Charron
>> >   > Sent: Wednesday, April 27, 2016 2:20 PM
>> >   > To: Anatol Belski <anatol@belski.net
>> > <mailto:anatol@belski.net> >
>> >   > Cc: Davey Shafik <da...@php.net <mailto:da...@php.net> >; PHP
>> > internals <internals@lists.php.net <mailto:internals@lists.php.net> >;
>> >   > paj...@php.net <mailto:paj...@php.net>
>> >   > Subject: Re: [PHP-DEV] Re: ext/curl update
>> >   >
>> >   > I agree, but I don't really now how I could test those things
>> since they
>> > almost all
>> >   > of the time only affect how libcurl will handle the
>> request/cache and
>> > we have no
>> >   > way to retrieve options like curl_easy_getopt or something
>> similar.
>> >   >
>> >   > On 27 April 2016 at 02:46, Anatol Belski <anatol@belski.net
>> > <mailto:anatol@belski.net>
>> >   > <mailto:anatol@belski.net <mailto:anatol@belski.net> >
>> >
>> > wrote:
>> >   >
>> >   >
>> >   >   Hi,
>> >   >
>> >   >   > -Original Message-
>> >   >   > From: m...@daveyshafik.com <mailto:m...@daveyshafik.com>
>> > <mailto:m...@daveyshafik.com <mailto:m...@daveyshafik.com> >
>> >   > [mailto:m...@daveyshafik.com <mailto:m...@daveyshafik.com>
>> > <mailto:m...@daveyshafik.com <mailto:m...@daveyshafik.com> > ] On Behalf Of
>> >   > Davey
>> >   >   > Shafik
>> >   >   > Sent: Sunday, April 24, 2016 2:25 AM
>> >   >   > To: Pierrick Charron <pierr...@adoy.net
>> > <mailto:pierr...@adoy.net>  <mailto:pierr...@adoy.net
>> > <mailto:pierr...@adoy.net> > >
>> >   >   > Cc: PHP internals <internals@lists.php.net
>> > <mailto:internals@lists.php.net>
>> >
>> >   > <mailto:internals@lists.php.net <mailto:internals@lists.php.net>
>> > >;
>> > paj...@php.net <mailto:paj...@php.net>  <mailto:paj...@php.net
>> > <mailto:paj...@php.net> >
>> >   >   > Subject: [PHP-DEV] Re: ext/curl update
>> >   >   >
>> >   >   > Hi Pierrick,
>> >   >   >
>> >   >   > This should be in master for 7.1, alongside my RFC'ed
>>

Re: [PHP-DEV] Re: ext/curl update

[Pierrick Charron]

Yep I'll check if I can add some test that could be easy to implement using
curl_easy_getinfo or using the php local server. Otherwise not sure we
could easily compile PHP with all those libcurl versions...


On 27 April 2016 at 11:37, Anatol Belski <anatol@belski.net> wrote:

> Hi,
>
> > -Original Message-
> > From: pierr...@webstart.fr [mailto:pierr...@webstart.fr] On Behalf Of
> Pierrick
> > Charron
> > Sent: Wednesday, April 27, 2016 2:20 PM
> > To: Anatol Belski <anatol@belski.net>
> > Cc: Davey Shafik <da...@php.net>; PHP internals <internals@lists.php.net
> >;
> > paj...@php.net
> > Subject: Re: [PHP-DEV] Re: ext/curl update
> >
> > I agree, but I don't really now how I could test those things since they
> almost all
> > of the time only affect how libcurl will handle the request/cache and we
> have no
> > way to retrieve options like curl_easy_getopt or something similar.
> >
> > On 27 April 2016 at 02:46, Anatol Belski <anatol@belski.net
> > <mailto:anatol@belski.net> > wrote:
> >
> >
> >   Hi,
> >
> >   > -Original Message-
> >   > From: m...@daveyshafik.com <mailto:m...@daveyshafik.com>
> > [mailto:m...@daveyshafik.com <mailto:m...@daveyshafik.com> ] On Behalf Of
> > Davey
> >   > Shafik
> >   > Sent: Sunday, April 24, 2016 2:25 AM
> >   > To: Pierrick Charron <pierr...@adoy.net  pierr...@adoy.net> >
> >   > Cc: PHP internals <internals@lists.php.net
> > <mailto:internals@lists.php.net> >; paj...@php.net  paj...@php.net>
> >   > Subject: [PHP-DEV] Re: ext/curl update
> >   >
> >   > Hi Pierrick,
> >   >
> >   > This should be in master for 7.1, alongside my RFC'ed patch for
> server
> > push
> >   > support.
> >   >
> >   > You emailed me directly about the aforementioned patch so I'll
> just
> > respond
> >   > here as it's relevant:
> >   >
> >   > The patch should hit in 7.1 but it has been requested that tests
> be
> > added — and
> >   > we can't add tests with a server push supporting HTTP/2 server
> against
> > which to
> >   > push.
> >   >
> >   As from the patch, many constants have nothing to do with HTTP/2
> > implementation and add just name/value without any further logic. If
> there were
> > a reduced patch with only such cases, it would be acceptable for 7.0 as
> well and
> > there were probably no collisions expected. What do you think?
> >
> So far I understood tests are exactly about HTTP2. Not sure how you would
> tests all the constants present in libcurl. Would need to rebuild with a
> dozen libcurl versions, but the documentation and compile time version
> check are already reliable things.
>
> Thanks
>
> anatol
>
>
>

Re: [PHP-DEV] Re: ext/curl update

[Pierrick Charron]

I agree, but I don't really now how I could test those things since they
almost all of the time only affect how libcurl will handle the
request/cache and we have no way to retrieve options like curl_easy_getopt
or something similar.

On 27 April 2016 at 02:46, Anatol Belski <anatol@belski.net> wrote:

> Hi,
>
> > -Original Message-
> > From: m...@daveyshafik.com [mailto:m...@daveyshafik.com] On Behalf Of Davey
> > Shafik
> > Sent: Sunday, April 24, 2016 2:25 AM
> > To: Pierrick Charron <pierr...@adoy.net>
> > Cc: PHP internals <internals@lists.php.net>; paj...@php.net
> > Subject: [PHP-DEV] Re: ext/curl update
> >
> > Hi Pierrick,
> >
> > This should be in master for 7.1, alongside my RFC'ed patch for server
> push
> > support.
> >
> > You emailed me directly about the aforementioned patch so I'll just
> respond
> > here as it's relevant:
> >
> > The patch should hit in 7.1 but it has been requested that tests be
> added — and
> > we can't add tests with a server push supporting HTTP/2 server against
> which to
> > push.
> >
> As from the patch, many constants have nothing to do with HTTP/2
> implementation and add just name/value without any further logic. If there
> were a reduced patch with only such cases, it would be acceptable for 7.0
> as well and there were probably no collisions expected. What do you think?
>
> Regards
>
> Anatol
>
>

Re: [PHP-DEV] [RFC] PHP Attributes

[Pierrick Charron]

On 27 April 2016 at 03:27, Dmitry Stogov <dmi...@zend.com> wrote:

>
>
> On 04/27/2016 08:25 AM, Pierrick Charron wrote:
>
> Hi all,
>
> First of all thanks dmitry for your great work and for bringing the RFC
> back to life.
>
> I think it would be great to allow users to define their own annotations
> and give them some structure (what the annotation is made of). For example
> let's say I apply an annotation to define that a property is a string with
> a length. In the proposed RFC I will have something like this :
>
> class Foo {
> <<MyAnnotation\StringLength(10)>>
> public string $bar;
> }
>
> But how could i know for example that StringLength can take an extra
> parameters I would have to read the code of the annotation framework see
> how it parse, use it etc... But if I can define the structure (this is a
> quickly invented pseudo syntax and I'm not proposing it)
>
> annotation MyAnnotation\StringLength {
> private int $length;
> private string $comment = "Default value";
> }
>
> With this definition I know that the Annotation take 2 parameters one int
> and one string, that the comment has a default value and can be omitted
> etc...
>
> Also what I dislike about using a simple array with no definition is that
> you can't annotate an annotation since there is no definition. I know it
> can look complex but think about the power you can add to the system. It
> would help us solve some problems that could not be solved (or at least I
> can't see any way of doing it) if you can't have a definition you can't
> attach behaviour/metadata to it.
>
> Here are some problems we could solve (those are just examples)
>
> 1. Are annotations inhereted or not ? Some will say yes, some now but I
> think they actually both make sense. For example we could imagine that if I
> annotate a method of my interface as deprecated I want it to be inhereted
> because all implementations are, but author annotation should not be
> inherited because I'm not necessarily the author of the implementation. So
> we could say that annotations are by default not inherited and we could
> have an <> annotation
>
> <>
> annotation deprecated {
> }
>
> annotation author {
> public string $name;
> public string $mail;
> }
>
> 2. Is a specific kind of annotation applicable to only one kind of
> statement or multiple ? JIT don't make sense on a property...
>
> <<Target(Target::METHOD)>>
> annotation jit {
> }
>
> 3. Current version of the RFC propose that we could either have AST or to
> execute the AST but we could imagine to get both
>
> annotation assert {
> <>
> public ast\node $node;
> public string $message;
> }
>
> Again, this is just a couple of quick ideas, but this would make things
> less magic/obscure with a definition and far more flexible. If we agree
> that we want a definition we could work on how to create this definition
> (we could use some stuff from the old Annotations RFC
> <https://wiki.php.net/rfc/annotations?rev=1302087566>
> https://wiki.php.net/rfc/annotations?rev=1302087566) to update this one
> with a new syntax or use interface as proposed in the first implementation
>
> class Deprecated implements Annotation {
> }
>
> Maybe
>
>
> didn't you think, that these annotation over-design made your RFC fail?
>

You maybe right, but the RFC was rejected 5 years ago and sometime people
change their mind, that's why I want to get people thought about it as of
today. If people still think the same that's fine with me, I'm just
exposing for people new to it other possibilities.


>
> You can't create objects at compile-time, and should delay their creation
> until Reflection*::getAttributes().
> Returning objects directly form Reflection*::getAttributes() doesn't
> improve flexibility at all.
> This would just increase the complexity of the patch...
>

I agree that this would increase the complexity of the patch but from time
to time we have to do complex things :-) the Zend Engine is full of them
and even if I agree that this should be avoided if possible it's sometime a
necessity. But again this is just my opinion and I'll respect the
community's decision.


>
> As I already said many times, all this extensions are possible to do in
> few PHP lines on top of base functionality.
> See "Doctrine use-case" at https://wiki.php.net/rfc/attributes#use_cases
>
> If you add these extensions directly into PHP implementation in C, you''ll
> have to support them, and you'll always miss some needs for "last
> use-case", but you won't able to change PHP behavior between major PHP
> versions.
>
> Thanks. Dmitry.
>
>
>
> Pierrick
>
>
>

Re: [PHP-DEV] [RFC] PHP Attributes

[Pierrick Charron]

Hi all,

First of all thanks dmitry for your great work and for bringing the RFC
back to life.

I think it would be great to allow users to define their own annotations
and give them some structure (what the annotation is made of). For example
let's say I apply an annotation to define that a property is a string with
a length. In the proposed RFC I will have something like this :

class Foo {
<>
public string $bar;
}

But how could i know for example that StringLength can take an extra
parameters I would have to read the code of the annotation framework see
how it parse, use it etc... But if I can define the structure (this is a
quickly invented pseudo syntax and I'm not proposing it)

annotation MyAnnotation\StringLength {
private int $length;
private string $comment = "Default value";
}

With this definition I know that the Annotation take 2 parameters one int
and one string, that the comment has a default value and can be omitted
etc...

Also what I dislike about using a simple array with no definition is that
you can't annotate an annotation since there is no definition. I know it
can look complex but think about the power you can add to the system. It
would help us solve some problems that could not be solved (or at least I
can't see any way of doing it) if you can't have a definition you can't
attach behaviour/metadata to it.

Here are some problems we could solve (those are just examples)

1. Are annotations inhereted or not ? Some will say yes, some now but I
think they actually both make sense. For example we could imagine that if I
annotate a method of my interface as deprecated I want it to be inhereted
because all implementations are, but author annotation should not be
inherited because I'm not necessarily the author of the implementation. So
we could say that annotations are by default not inherited and we could
have an <> annotation

<>
annotation deprecated {
}

annotation author {
public string $name;
public string $mail;
}

2. Is a specific kind of annotation applicable to only one kind of
statement or multiple ? JIT don't make sense on a property...

<>
annotation jit {
}

3. Current version of the RFC propose that we could either have AST or to
execute the AST but we could imagine to get both

annotation assert {
<>
public ast\node $node;
public string $message;
}

Again, this is just a couple of quick ideas, but this would make things
less magic/obscure with a definition and far more flexible. If we agree
that we want a definition we could work on how to create this definition
(we could use some stuff from the old Annotations RFC
https://wiki.php.net/rfc/annotations?rev=1302087566) to update this one
with a new syntax or use interface as proposed in the first implementation

class Deprecated implements Annotation {
}

Maybe

Pierrick

Re: [PHP-DEV] [RFC] PHP Attributes

[Pierrick Charron]

And it will probably be in conflict with the Short Array Syntax ?

On 26 April 2016 at 13:14, Dmitry Stogov  wrote:

> Just because HHVM is closer to PHP than C#.
>
>
> 
> From: Dominic Grostate 
> Sent: Tuesday, April 26, 2016 19:43
> To: Dmitry Stogov
> Cc: rowan.coll...@gmail.com; PHP internals; Stanislav Malyshev
> Subject: Re: [PHP-DEV] [RFC] PHP Attributes
>
>
> Why not like C#?
>
> [Description("My Function")]
> function my_function()
> {}
>
> Without the semicolon, this wouldn't be valid in any other context.
>
> On 26 Apr 2016 8:41 a.m., "Dmitry Stogov" > wrote:
>
>
> On 04/25/2016 11:20 PM, Stanislav Malyshev wrote:
> Hi!
>
> No, but this is valid:
>
> @atrr(); function foo() { ... }
>
> That's perhaps a little too close for comfort...?
> That's different syntax. If you put ; in the middle of statement, it can
> change - "$c = $a + $b;" is not the same as "$c = $a; + $b;" - but
> nobody thinks + can not be used because of that. As I said, << and >>
> are existing operators too, so if you are creative enough, I'm sure you
> can find cases like that too.
>
> Hi Stas,
>
> You may try to replace attribute syntax with @attr(...) (without
> semicolon) into our PHP parser.
> Note that we have LALR grammar + restrictions caused by semantic actions.
> If you are able to do this, I'll add it into the RFC as an option.
>
> Thanks. Dmitry.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Re: ext/curl update

[Pierrick Charron]

Hi Davey,

Thanks for your answer. I still have small projects on my pipeline that I
want to finish but I'll start looking at libnghttp2 and if I get some time
I'll recontact you to maybe help you on remaining tasks :-) Do you have
specifics stuffs that you would like me to look at ?

About the patch if there is no objection i'll commit it to the 7.1 branch
soon.

Pierrick

On 23 April 2016 at 20:24, Davey Shafik <da...@php.net> wrote:

> Hi Pierrick,
>
> This should be in master for 7.1, alongside my RFC'ed patch for server
> push support.
>
> You emailed me directly about the aforementioned patch so I'll just
> respond here as it's relevant:
>
> The patch should hit in 7.1 but it has been requested that tests be added
> — and we can't add tests with a server push supporting HTTP/2 server
> against which to push.
>
> I'm working with Pierre Joye (CC'ed) to try and update the cli-server to
> use libnghttp2 to turn it into a fully fledged HTTP/2 compliant server with
> support for server push and things like multiplexing (see:
> http://wiki.php.net/rfc/cli_server_http2). Curl also uses libnghttp2 for
> it's HTTP/2 support.
>
> I hope to eventually (7.2+) use libnghttp2 to add an ext/nghttp2 HTTP
> client and update the HTTP streams layer to support HTTP/2 also.
>
> I'd welcome your collaboration on any of this.
>
> - Davey
>
> On Sat, Apr 23, 2016 at 12:30 PM, Pierrick Charron <pierr...@adoy.net>
> wrote:
>
>> Hi internals,
>>
>> I took some time to add some easy to implement new "features" that were
>> implemented in libcurl but missing in ext/curl. Most of them are just
>> exposing a new constant in ext/curl and dispatched in the curl_setopt
>> function. I created a branch over master but the patch is applicable
>> without conflict the 7.0 branch.
>>
>> https://github.com/php/php-src/compare/master...adoy:curl-update
>>
>> I was wondering since it's not a big patch and it only introduce new
>> constants :
>>
>> - Should I commit this patch to 7.0 and master or only master
>> - Should I do a RFC to include this patch ?
>>
>> Thanks for your feedback
>> Pierrick
>>
>>
>>
>>
>>
>>
>>
>

[PHP-DEV] ext/curl update

[Pierrick Charron]

Hi internals,

I took some time to add some easy to implement new "features" that were
implemented in libcurl but missing in ext/curl. Most of them are just
exposing a new constant in ext/curl and dispatched in the curl_setopt
function. I created a branch over master but the patch is applicable
without conflict the 7.0 branch.

https://github.com/php/php-src/compare/master...adoy:curl-update

I was wondering since it's not a big patch and it only introduce new
constants :

- Should I commit this patch to 7.0 and master or only master
- Should I do a RFC to include this patch ?

Thanks for your feedback
Pierrick

Re: [PHP-DEV] [RFC] PHP Attributes

[Pierrick Charron]

On 22 April 2016 at 11:39, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov  wrote:
>
> >
> >
> > On 04/22/2016 04:05 AM, guilhermebla...@gmail.com wrote:
> >
> > Hi Dmitry,
> >
> > As a previous suggester of metadata information built-in into PHP, and
> > also one of developers of the most used metadata library written in PHP,
> I
> > understand this feature implementation requires several design decisions
> > and also a good understanding of specific situations users may require.
> >
> > While I am a strong supporter of a more robust solution, this is already
> a
> > good start.
> > A few things I'd like to ask for my own understanding and also
> suggestions
> > too:
> >
> > 1- I understand you took a minimalistic approach towards a "dumb"
> > implementation for attributes (when I mean "dumb", the idea here is
> towards
> > a non-OO approach). Can you explain your motivations towards this
> approach?
> >
> > I see two distinct approaches of implementation for this feature. Both of
> > them have some common demands, like lazy initialization of metadata. Here
> > they are:
> >
> > - Simplistic approach, which lets consumers of the feature do all the
> work
> > related to validation, assertion of valid keys, values, etc
> > This does not invalidate the ability to leverage of some features that a
> > more robust implementation demands.
> >
> > - Robust approach: language takes the burden of instantiating complex
> > structures, validating, assertion of valid keys, values, if this complex
> > structure is allowed to be instantiated in that given class, method, etc.
> >
> >
> > I didn't exactly understand what do you suggest.
> > If you are talking about Attribute objects initialization during
> > compilation - this is just not possible from implementation point of
> view.
> > Now attributes may be stored in opcache SHM and relive request boundary.
> > Objects can't relive requests.
> >
>
>
> I know that object instances are not cross-requests. Explicitly, I
> mentioned that both approaches require lazy-initialization (which means,
> whenever you call getAttributes() or getAttribute()).
>
> What I mentioning is that your approach is basically a new key/value syntax
> that are used specifically for Attributes. We could easily turn this into a
> more robust approach if instead of defining key/value pairs, we instantiate
> objects or call functions. You already demonstrated interest to support
> <> reusing the imports (which is our biggest headache in
> Doctrine Annotations), so why not issue constructor or function calls
> there? That would simplify the work needed for consumers and also add room
> for later improvements.
>
> So basically in this example:
>
> use Doctrine\ORM;
>
> <>
> class User {}
>
> $reflClass = new \ReflectionClass("User");
> var_dump($reflClass->getAttributes());
>
> We'd be changing from this:
>
> array(1) {
>   ["Doctrine\ORM\Entity"]=>
>   array(1) {
> [0]=>
> string(4) "user"
>   }
> }
>
> Into this:
>
> array(1) {
>   ["Doctrine\ORM\Entity"]=>
>   object(Doctrine\ORM\Entity)#1 (1) {
> ["tableName"]=>
> string(4) "user"
>   }
> }
>

+1


>
>
> >
> > 1- Your approach is basically defining an array. Could you explain your
> > line of thinking on why you didn't consider a syntax like the one below?
> >
> > <["key" => "value"]>
> > class Foo {}
> >
> > I didn't try to invite new syntax. Just completely took it from HHVM.
> >
>
> My idea was based on your current proposal, which is basically a way to
> define key/value pairs.
> If you decide to go minimalistic, that is probably my best line of
> thinking.
>
>
> >
> >
> >
> > 2- I see that you added support over functions, classes, constants and
> > properties. According to the RFC, getAttributes() was added over
> > ReflectionFunction. Is there a reason why support was not added to
> methods
> > (ReflectionMethod extends ReflectionFunctionAbstract, which was not
> > mentioned on RFC)? Any reason to not support it in function/method
> > parameters?
> >
> > ReflectionMethod is a child of ReflectinFunction, so it's supported.
> >
> Attributes are allowed for the same entities as doc-comments (they are not
> > allowed for parameters)
> >
>
> I was asking if there was a purpose to not support Attributes over
> ReflectionParameter. Example:
>
> class Foo {
> public function bar(<> Bar $bar) : bool {
> // ...
> }
> }
>
> $reflClass = new \ReflectionClas("Foo");
> $reflMethod = $reflClass->getMethod("bar");
> $reflParameter = $reflMethod->getParameters()[0];
>
> var_dump($reflParameter->getAttributes());
>
>
> >
> >
> >
> > 3- Did you put any thought on inheritance? What I mentioned in comment #1
> > is even smaller than what you implemented in RFC.
> > Assuming you keep the RFC approach, did you consider support overrides,
> > inherit, etc?
> >
> >
> > In my opinion, attributes don't have to be inherited.

Re: [PHP-DEV] [RFC Discussion] Catching multiple exception types

[Pierrick Charron]

Thanks for the feedback Patrick :-) I understand your concern. I added a
section to the RFC Impact section to mention that PHP tools/IDE will
require some modifications. Feel free to add some additional details in
this section if you want. People who will vote will then be aware of the
situation and I'll of course comply to the voters decision :-)

Pierrick

On 15 March 2016 at 12:23, Patrick ALLAERT <patrickalla...@php.net> wrote:

> Hi,
>
> Le mer. 9 mars 2016 à 14:08, Marco Pivetta <ocram...@gmail.com> a écrit :
>
>> On 9 March 2016 at 14:03, Pierrick Charron <pierr...@adoy.net> wrote:
>>
>> > Hi Derick
>> >
>> > I agree that most of the time the best solution is to implement a clean
>> > exception hierarchy but as stated in the RFC :
>> >
>> > "A solution to fix this problem on the user level would be to implement
>> a
>> > common interface for ExceptionType1 and ExceptionType2 and catch it.
>> > However, this is only possible when you control the exception hierarchy
>> in
>> > your own code, but not possible when you don't control the code."
>> >
>>
>> I understand the use-case, but I don't see it as a widespread scenario. In
>> most cases, I've been doing something like following:
>>
>> public function stuff()
>> {
>> try {
>> $this->willFail();
>> } catch (FirstException $e) {
>> $this->handleFailure($e);
>> } catch (SecondException $e) {
>> $this->handleFailure($e);
>> } catch (ThirdException $e) {
>> $this->handleFailure($e);
>> }
>> }
>>
>> Even then, this is a rare eventuality, and as pointed out above, usually
>> fixed when wrapping exceptions correctly, if you have control over the
>> exception types).
>> Seems way below the 80/20 use-case to me, and introduces syntax changes as
>> well.
>
>
> +1
>
> I will add to this that Exceptions must remain... exceptional! Too much
> projects relies already on tens or hundreds of business exception while
> those are mostly common "error" conditions that are better handled with
> dedicated API calls.
>
> To me, it doesn't look like a reasonable change when we consider the
> number of tools/IDE to adapt compared to the possible usage of it.
>
> Cheers,
> Patrick
>

Re: [PHP-DEV] [RFC Discussion] Catching multiple exception types

[Pierrick Charron]

Thanks for your feedback !

Any other thoughts from anyone else on this ?

On 10 March 2016 at 02:31, Björn Larsson <bjorn.x.lars...@telia.com> wrote:

> Hi, Thanks for clarifying. Think the RFC would benefit from having
> some of these examples in it. I also had in mind that it's handy for
> catching many exceptions when logging stuff and re-throwing like:
>
> }  catch (FirstException | SecondException ex) {
> logger.error(ex);
> throw ex;
> }
>
> Regards //Björn
>
> PS Sorry for top-posting...
>
>
> Den 2016-03-09 kl. 08:05, skrev Bronisław Białek:
>
>> Hi :)
>>
>> I think it is feature that is useful time to time, not very often.
>> One example:
>>
>> class PackingFailed extends \Exception implements PackagingException {}
>>
>> // this exception could originate from package with assertions/exceptions,
>> // so I cannot use common interface with above
>> class EmptyName extends \Exception implements ValidationException {}
>>
>> class Packer
>> {
>>  /** @throws PackingFailed */
>>  public function pack(PackTemplate $packTemplate) : Pack
>>  {
>>  try {
>>  return $this->save($packTemplate);
>>  } catch (IOException $e) {
>>  throw new PackingFailed('', 0, $e);
>>  }
>>  }
>> }
>>
>> class PackTemplate
>> {
>>  /** @throws EmptyName */
>>  public function __construct(string $name)
>>  {
>>  if ($name === '') {
>>  throw new EmptyName();
>>  }
>>  }
>> }
>>
>> /** @throws SomeException */
>> function packeForMe(string $name) : Pack
>> {
>>  try {
>>  return (new Packer())->pack(new PackTemplate($name));
>>  } catch (PackingFailed | ValidationException $e) {
>>  throw new SomeException($e); // or return null in other cases
>>  }
>> }
>>
>>
>> 2016-03-09 2:47 GMT+01:00 Pierrick Charron <pierr...@adoy.net>:
>>
>> Hi Björn,
>>>
>>> The only time I had to do this with core PHP exceptions is to make the
>>> code compatible for both PHP5 and PHP7:
>>>
>>> try {
>>> } catch(\Exceptions $e) {
>>> } catch(\Throwable $e) {
>>> }
>>>
>>> But it will of course not be applicable since this feature is targeting
>>> PHP7.1. Other than that the PHP core exception hierarchy is well enough
>>> for
>>> MY needs. But if someone already had to do this fill free to provide your
>>> use case as an example.
>>>
>>> My main target is custom exceptions (even if the logic is applicable on
>>> everything Throwable). A custom exception use case would be some method
>>> that throw thwo different kind of exceptions like for example the
>>> doctrine
>>> AbstractQuery::getSingleResult (NoResultException,
>>> NonUniqueResultException) that you could want to handle the same way.
>>>
>>> An other really easy example would be simple code like this one that I
>>> found in symfony (not really a big deal but still)
>>>
>>> } catch (AccessException $e) {
>>>  return false;
>>> } catch (UnexpectedTypeException $e) {
>>> return false;
>>> }
>>>
>>> And other piece of code using multiple libraries.
>>>
>>>
>>> On 8 March 2016 at 18:06, Björn Larsson <bjorn.x.lars...@telia.com>
>>> wrote:
>>>
>>> Den 2016-03-08 kl. 22:42, skrev Pierrick Charron:
>>>>
>>>> Hi internals,
>>>>>
>>>>> Bronisław Białek and I would like to start a discussion about allowing
>>>>> multiple exception types to be caught in a single catch statement.
>>>>>
>>>>> https://wiki.php.net/rfc/multiple-catch
>>>>>
>>>>> A working implementation and tests are available in the RFC.
>>>>>
>>>>> We are waiting for your constructive feedback and thoughts.
>>>>>
>>>>> Thanks
>>>>> Pierrick
>>>>>
>>>>> Nice RFC! Think it would be good if you had an example in the
>>>>>
>>>> RFC showing the applicability of catching two php exceptions.
>>>> Especially given the new exception hierarchy in PHP 7. I'm also
>>>> pondering if the main target for this is custom exceptions or
>>>> the built-in ones or both?
>>>>
>>>> Regards //Björn Larsson
>>>>
>>>> PS
>>>>
>>>>
>>>
>>
>

Re: [PHP-DEV] [RFC Proposal] Null Coalesce Equal Operator

[Pierrick Charron]

Hi Sara,

Just to let you know that I took the liberty to correct the title of your
RFC. It was still null coalesce equal operator :)

Otherwise I'm +1 for both RFC

Pierrick

On 10 March 2016 at 22:01, Sara Golemon  wrote:

> On Wed, Mar 9, 2016 at 10:14 AM, Midori Kocak  wrote:
> > Let me introduce my first RFC here:
> https://wiki.php.net/rfc/null_coalesce_equal_operator >
> >
> I've jumped on the bandwagon by adding a second RFC related to this
> one: https://wiki.php.net/rfc/short_ternary_equal_operator which
> focused on the short-ternary operator with the same goal of creating
> and assignment version of the operation.
>
> We can probably discuss them as a single concept since they relate to
> the same underlying principle (consistency in binary operations in the
> language), but I made it a separate RFC in case we want different
> voting or have different concerns regarding them.
>
> If that's a terrible idea, I can close the new one and let Midori add
> ?: to her original RFC.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC Discussion] Catching multiple exception types

[Pierrick Charron]

On 9 March 2016 at 08:30, Marco Pivetta <ocram...@gmail.com> wrote:

> On 9 March 2016 at 14:24, Pierrick Charron <pierr...@adoy.net> wrote:
>>
>> The thing I don't like about this approach is that I have to read the
>> code and double check to make sure that the catch statement call the same
>> method.
>> For the amount of work that needs to be done in the Engine (see the patch
>> attached to the RFC) this is far more readable and it is clear that the
>> code to handle those 3 exceptions is the exact same one. And if the code of
>> handleFailure is small you can even put it at this single place.
>>
>> public function stuff()
>> {
>> try {
>> $this->willFail();
>> } catch (FirstException | SecondException | ThirdException $e) {
>> $this->handleFailure($e);
>> }
>> }
>>
>>
> I'd still have to write 3 test cases anyway: no real amount of
> code-savings there.
>

Agree


>
> I still think the first solution is as readable as the one you proposed
> there.
>

Agree to disagree ;-)


> The change in the PHP engine might be trivial, but the syntax change from
> a userland perspective is a mess (tooling, pretty much anything that relies
> on an AST parser needs changes there).
> Do not underestimate language changes as a php-core only issue.
>

You're right but I think those impact should not prevent us to make the
language evolve even for small changes that are just like this one
syntactic sugar. With the amount of user doing PHP code on a daily basis
those changes are IMO worth it.


>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>

Re: [PHP-DEV] [RFC Discussion] Catching multiple exception types

[Pierrick Charron]

On 9 March 2016 at 08:08, Marco Pivetta <ocram...@gmail.com> wrote:

> On 9 March 2016 at 14:03, Pierrick Charron <pierr...@adoy.net> wrote:
>
>> Hi Derick
>>
>> I agree that most of the time the best solution is to implement a clean
>> exception hierarchy but as stated in the RFC :
>>
>> "A solution to fix this problem on the user level would be to implement a
>> common interface for ExceptionType1 and ExceptionType2 and catch it.
>> However, this is only possible when you control the exception hierarchy in
>> your own code, but not possible when you don't control the code."
>>
>
> I understand the use-case, but I don't see it as a widespread scenario. In
> most cases, I've been doing something like following:
>
>
I agree that this the RFC will not get the oscar for feature of the year,
but I think it will lead in those few use-case to more readable code.


> public function stuff()
> {
> try {
> $this->willFail();
> } catch (FirstException $e) {
> $this->handleFailure($e);
> } catch (SecondException $e) {
> $this->handleFailure($e);
> } catch (ThirdException $e) {
> $this->handleFailure($e);
> }
> }
>
>
The thing I don't like about this approach is that I have to read the code
and double check to make sure that the catch statement call the same method.
For the amount of work that needs to be done in the Engine (see the patch
attached to the RFC) this is far more readable and it is clear that the
code to handle those 3 exceptions is the exact same one. And if the code of
handleFailure is small you can even put it at this single place.

public function stuff()
{
try {
$this->willFail();
} catch (FirstException | SecondException | ThirdException $e) {
$this->handleFailure($e);
}
}

Even then, this is a rare eventuality, and as pointed out above, usually
> fixed when wrapping exceptions correctly, if you have control over the
> exception types).
> Seems way below the 80/20 use-case to me, and introduces syntax changes as
> well.
>
> Cheers,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>

Re: [PHP-DEV] [RFC Discussion] Catching multiple exception types

[Pierrick Charron]

Hi Derick

I agree that most of the time the best solution is to implement a clean
exception hierarchy but as stated in the RFC :

"A solution to fix this problem on the user level would be to implement a
common interface for ExceptionType1 and ExceptionType2 and catch it.
However, this is only possible when you control the exception hierarchy in
your own code, but not possible when you don't control the code."

On 9 March 2016 at 06:52, Derick Rethans <der...@php.net> wrote:

> Hi!
>
> On Tue, 8 Mar 2016, Pierrick Charron wrote:
>
> > Bronisław Białek and I would like to start a discussion about allowing
> > multiple exception types to be caught in a single catch statement.
> >
> > https://wiki.php.net/rfc/multiple-catch
>
> Would it not be better, to have your Exceptions extend a common base
> class in this case? Or perhaps, which I think is even better, to have
> your Exception classes implement a common interface that you can catch
> against. That I believe should already work.
>
> What you are asking PHP users to do with a multiple catch like this, is
> to test in each catch's statement block to test for each class again.
> Neither the inheritence or implements options from the previous
> paragraph have that issue.
>
> cheers,
> Derick

Re: [PHP-DEV] [RFC Discussion] Catching multiple exception types

[Pierrick Charron]

Hi Björn,

The only time I had to do this with core PHP exceptions is to make the code
compatible for both PHP5 and PHP7:

try {
} catch(\Exceptions $e) {
} catch(\Throwable $e) {
}

But it will of course not be applicable since this feature is targeting
PHP7.1. Other than that the PHP core exception hierarchy is well enough for
MY needs. But if someone already had to do this fill free to provide your
use case as an example.

My main target is custom exceptions (even if the logic is applicable on
everything Throwable). A custom exception use case would be some method
that throw thwo different kind of exceptions like for example the doctrine
AbstractQuery::getSingleResult (NoResultException,
NonUniqueResultException) that you could want to handle the same way.

An other really easy example would be simple code like this one that I
found in symfony (not really a big deal but still)

} catch (AccessException $e) {
return false;
} catch (UnexpectedTypeException $e) {
return false;
}

And other piece of code using multiple libraries.


On 8 March 2016 at 18:06, Björn Larsson <bjorn.x.lars...@telia.com> wrote:

> Den 2016-03-08 kl. 22:42, skrev Pierrick Charron:
>
>> Hi internals,
>>
>> Bronisław Białek and I would like to start a discussion about allowing
>> multiple exception types to be caught in a single catch statement.
>>
>> https://wiki.php.net/rfc/multiple-catch
>>
>> A working implementation and tests are available in the RFC.
>>
>> We are waiting for your constructive feedback and thoughts.
>>
>> Thanks
>> Pierrick
>>
>> Nice RFC! Think it would be good if you had an example in the
> RFC showing the applicability of catching two php exceptions.
> Especially given the new exception hierarchy in PHP 7. I'm also
> pondering if the main target for this is custom exceptions or
> the built-in ones or both?
>
> Regards //Björn Larsson
>
> PS
>

Re: [PHP-DEV] [RFC Discussion] Catching multiple exception types

[Pierrick Charron]

Hi Sean and Yasuo

I agree that they are somehow related, but I also think (and I might be
wrong) that the behaviour of the Multi-Catch is obvious and I don't see how
this syntax/feature could be interpreted otherwise. The multi-catch don't
have any open-issue that the Union-Types have like weak types since it only
deals with Exceptions. Also, we still don't know if we'll one day have the
Union-Types since there are those open issues and it would be sad to wait
something that could never append. It's IMO pretty safe going forward and
if required in the future change the implementation when needed (Behaviour
will stay the same, unless you see other behaviour that this syntax could
have in this same "catch" context).

Pierrick

On 8 March 2016 at 16:50, Sean DuBois <s...@siobud.com> wrote:

> On Tue, Mar 08, 2016 at 04:42:29PM -0500, Pierrick Charron wrote:
> > Hi internals,
> >
> > Bronisław Białek and I would like to start a discussion about allowing
> > multiple exception types to be caught in a single catch statement.
> >
> > https://wiki.php.net/rfc/multiple-catch
> >
> > A working implementation and tests are available in the RFC.
> >
> > We are waiting for your constructive feedback and thoughts.
> >
> > Thanks
> > Pierrick
>
> Hi!
>
> It may be an issue that this is close in design to [0] union types.
> This RFC would be *great* for code quality, just might be a subset of
> union types.
>
> thanks
>
> [0] https://wiki.php.net/rfc/union_types
>

[PHP-DEV] [RFC Discussion] Catching multiple exception types

[Pierrick Charron]

Hi internals,

Bronisław Białek and I would like to start a discussion about allowing
multiple exception types to be caught in a single catch statement.

https://wiki.php.net/rfc/multiple-catch

A working implementation and tests are available in the RFC.

We are waiting for your constructive feedback and thoughts.

Thanks
Pierrick

Re: [PHP-DEV] Re: [VOTE] Removal of curl-wrappers

[Pierrick Charron]

David, All,

I just committed the patch to remove curl-wrappers from PHP5.5. It 's one
day before schedule but we need to make sure the merge was done before the
new beta release.

Pierrick


On 22 April 2013 13:10, Pierrick Charron pierr...@adoy.net wrote:

 Hi,

 The vote is supposed to end on April 24th, but if there is no objection, I
 will end it tomorrow and merge it if there is no change in the vote results.

 Pierrick


 On 22 April 2013 04:58, David Soria Parra d...@php.net wrote:

 On 2013-04-17, Pierrick Charron pierr...@adoy.net wrote:
  --001a11c37cdc78c2e304da95cfde
  Content-Type: text/plain; charset=ISO-8859-1
 
  Hi folks,
 
  I just opened a vote for the curl-wrappers removal in 5.5. Since we are
 in
  a tight schedule, the vote duration will only be a week and will end
 April
  24th.
 
  You can vote there :
 https://wiki.php.net/rfc/curl-wrappers-removal-rfc#vote

 As a friendly reminder. I tag beta4 on Wednesday around 10:00 UTC. Is this
 getting into before or not?

 David

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

Re: [PHP-DEV] Re: [VOTE] Removal of curl-wrappers

[Pierrick Charron]

Hi,

The vote is supposed to end on April 24th, but if there is no objection, I
will end it tomorrow and merge it if there is no change in the vote results.

Pierrick


On 22 April 2013 04:58, David Soria Parra d...@php.net wrote:

 On 2013-04-17, Pierrick Charron pierr...@adoy.net wrote:
  --001a11c37cdc78c2e304da95cfde
  Content-Type: text/plain; charset=ISO-8859-1
 
  Hi folks,
 
  I just opened a vote for the curl-wrappers removal in 5.5. Since we are
 in
  a tight schedule, the vote duration will only be a week and will end
 April
  24th.
 
  You can vote there :
 https://wiki.php.net/rfc/curl-wrappers-removal-rfc#vote

 As a friendly reminder. I tag beta4 on Wednesday around 10:00 UTC. Is this
 getting into before or not?

 David

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

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Pierrick Charron]

Hi,

Since we are in a tight schedule, I started the vote and it will end in a
week.

https://wiki.php.net/rfc/curl-wrappers-removal-rfc#vote

Pierrick


On 16 April 2013 09:17, Julien Pauli jpa...@php.net wrote:

 On Tue, Apr 16, 2013 at 3:01 PM, Pierrick Charron pierr...@adoy.netwrote:

 I created a straightforward RFC that you can access here
 https://wiki.php.net/rfc/curl-wrappers-removal-rfc .

 If someone have something more to add in it, feel free. Otherwise I will
 start the vote so that we could remove it in 5.5 ASAP.


 Thx Pierrick, it's ok for me :)

 Julien.Pauli

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Pierrick Charron]

Oh sorry I'm gonna do it right now.

Thanks :)


On 17 April 2013 18:02, Hannes Magnusson hannes.magnus...@gmail.com wrote:

 I think by law you have to create a new thread and prefix the subject
 line with [VOTE] or something.

 -Hannes

 On Wed, Apr 17, 2013 at 2:59 PM, Pierrick Charron pierr...@adoy.net
 wrote:
  Hi,
 
  Since we are in a tight schedule, I started the vote and it will end in a
  week.
 
  https://wiki.php.net/rfc/curl-wrappers-removal-rfc#vote
 
  Pierrick
 
 
  On 16 April 2013 09:17, Julien Pauli jpa...@php.net wrote:
 
  On Tue, Apr 16, 2013 at 3:01 PM, Pierrick Charron pierr...@adoy.net
 wrote:
 
  I created a straightforward RFC that you can access here
  https://wiki.php.net/rfc/curl-wrappers-removal-rfc .
 
  If someone have something more to add in it, feel free. Otherwise I
 will
  start the vote so that we could remove it in 5.5 ASAP.
 
 
  Thx Pierrick, it's ok for me :)
 
  Julien.Pauli
 

[PHP-DEV] [VOTE] Removal of curl-wrappers

[Pierrick Charron]

Hi folks,

I just opened a vote for the curl-wrappers removal in 5.5. Since we are in
a tight schedule, the vote duration will only be a week and will end April
24th.

You can vote there : https://wiki.php.net/rfc/curl-wrappers-removal-rfc#vote

Regards,
Pierrick

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Pierrick Charron]

I created a straightforward RFC that you can access here
https://wiki.php.net/rfc/curl-wrappers-removal-rfc .

If someone have something more to add in it, feel free. Otherwise I will
start the vote so that we could remove it in 5.5 ASAP.

Thanks
Pierrick

On 12 April 2013 11:09, Julien Pauli jpa...@php.net wrote:

 On Fri, Apr 12, 2013 at 4:09 PM, David Soria Parra d...@php.net wrote:

  On 2013-04-12, Johannes Schlüter johan...@schlueters.de wrote:
   5.3 users might depend on some part of the behavior and have learned to
   live with bugs. We shouldn't kick features at this stage.
 
  curlwrappers should definatly stay in 5.3 and 5.4. I have no problem
  with having them removed in 5.5 (with an RFC) but I prefer to have it
 done
  before beta4 as this is going to be our last beta. Removing it in
  RC phase would bend the meaning of stages in the release process even
 more.
 

 Right, as Pierrick already got a patch, I asked him if he could write an
 RFC.
 We dont need a too big RFC, it's mainly about removing the feature to a
 feature-branch.

 Julien.Pauli

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Pierrick Charron]

+1

On 12 April 2013 04:07, Johannes Schlüter johan...@schlueters.de wrote:

 On Fri, 2013-04-12 at 10:00 +0200, Julien Pauli wrote:
  On Fri, Apr 12, 2013 at 1:34 AM, Kalle Sommer Nielsen ka...@php.net
 wrote:
 
   Hi
  
   2013/4/12 Pierre Joye pierre@gmail.com:
On Thu, Apr 11, 2013 at 11:17 PM, Pierrick Charron 
 pierr...@adoy.net
   wrote:
Including 5.3 and 5.4 ??
  
   If removed in 5.3 and 5.4, theres no need for the constant anymore.
  
 
  Right :-)
 
  I agree with Pierre as well, we know this feature leads to bugs, is
  experimental, and is so not very very used.

 5.3 users might depend on some part of the behavior and have learned to
 live with bugs. We shouldn't kick features at this stage.

 johannes

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Pierrick Charron]

If you decide to remove it for 5.5 RC, tell me and I'll merge this branch
https://github.com/adoy/php-src/tree/remove-curl-wrappers

Thanks
Pierrick

On 11 April 2013 04:03, Julien Pauli jpa...@php.net wrote:

 On Wed, Apr 10, 2013 at 6:52 PM, Pierre Joye pierre@gmail.com wrote:

 On Wed, Apr 10, 2013 at 6:46 PM, Julien Pauli jpa...@php.net wrote:

  Beta3 has been taggued with curl wrappers, and with the new
  CURL_WRAPPERS_ENABLED constant :-p
 
  Do we all agree to remove that feature (meaning moving it to a branch,
 or
  somewhere for the interested developers to keep on making it stable)
 for 5.5
  stable or no ?

 I see no chance to get it stable for 5.5, the PECL way is the right
 and when it is stable we can re consider it.


 Ok, too bad we taggued beta3 with it. I suggest we remove this feature
 when going RC so.

 Thx all,

 Julien.Pauli

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Pierrick Charron]

Including 5.3 and 5.4 ??

Pierrick

On 11 April 2013 14:12, Pierre Joye pierre@gmail.com wrote:

 On Thu, Apr 11, 2013 at 4:54 PM, Pierrick Charron pierr...@adoy.net
 wrote:
  If you decide to remove it for 5.5 RC, tell me and I'll merge this branch
  https://github.com/adoy/php-src/tree/remove-curl-wrappers

 s,5.5,all branches,


 Cheers,
 --
 Pierre

 @pierrejoye

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Pierrick Charron]

Hi

I don't think we should remove curlwrappers from 5.5. I do agree that this
is not yet stable and ready to push as non experimental, but since we plan
to release 5.5 soon I don't think removing it right now is worth it.

I started some time ago to maintain the curl extension. I focused mainly on
adding to ext/curl all options from the libcurl api that were not available
in PHP userspace. I also fixed some bugs on curlwrappers and will be please
to fix (or at least try to fix) all bugs that we may have with curl and
curl wrappers in the hope that it will be stable enough to be release with
php nexté

If you have a bug with curlwrapper (or anything related to ext/curl) please
assign me the bug on the tracker and I will try to look at them ASAP.

Thanks

Pierrick



On 4 April 2013 09:49, Julien Pauli jpa...@php.net wrote:

 IMO , we should remove that feature from 5.5.

 If Laruence is OK to maintain it, then we keep it, but Laruence, please,
 improve it so.
 We keep it if Laruence can make it stable for 5.5 final. If he cant , or
 doesn't want to work on it any more while in betas ; then we should remove
 curlwrapper from 5.5.

 Laruence: If you (or someone else) are motivated to work on it and feel all
 right to turn it to a stable feature without breaking streams or other
 stuff , then we will discuss a way to detect it.

 Why not parse the configure options by adding a new way to do it ?
 I'm writing a mail about that now.

 Thanks.

 Julien.P

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

[Pierrick Charron]

 Protip: use an IDE.


The IDE that i'm using may search for something like function \w to find
all the functions of my code. So I may have to wait for a new update of the
IDE to be able to use the index, and I also may have to pay to get the
update of my IDE. So why would I want all this if I can just keep the
function keyword.

Pierrick

Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists

[Pierrick Charron]

+1

On 19 February 2013 07:06, Sara Golemon poll...@php.net wrote:

 Opening RFC to allow trailing comma in function call argument lists

 https://wiki.php.net/rfc/trailing-comma-function-args

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

Re: [PHP-DEV] Zend Optimizer+ Source Code now available

[Pierrick Charron]

That's a good idea :) I'm also in

On 13 February 2013 09:51, Zeev Suraski z...@zend.com wrote:


 As per Derick’s idea, we can arrange a webinar for those interested in
 better understanding how it works.

Re: [PHP-DEV] Zend Optimizer+ Source Code now available

[Pierrick Charron]

Hi,

I tried to install the ZendOptimizer+ provided earlier today but wasn't
able to make it work. I compiled it with success but when I looked at the
phpinfo(); I had this :

Opcode Caching Disabled
Optimization Enabled
Startup Failed no value

I'm using the apache2handler (MPM Worker - multi-threaded), PHP Version
5.4.13-dev.

Here's my configure :

'./configure' '--enable-debug' '--enable-bcmath' '--enable-calendar'
'--enable-gd-native-ttf' '--enable-maintainer-zts' '--enable-mbstring'
'--enable-soap' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-zip' '--with-apxs2=/usr/bin/apxs2'
'--with-config-file-path=/etc/php5/PHP-5.4'
'--with-config-file-scan-dir=/etc/php5/PHP-5.4/conf.d' '--with-curl'
'--with-freetype-dir=/usr/lib' '--with-gd' '--with-jpeg-dir'
'--with-kerberos' '--with-mcrypt'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysql=mysqlnd'
'--with-mysqli=mysqlnd' '--with-openssl' '--with-pdo-mysql=mysqlnd'
'--with-png-dir' '--with-readline' '--with-xsl' '--with-zlib-dir'

I only added the zend_extension line in my php.ini file.

I tried to look at the log but did not found anything that could explain
why the Startup Failed. I looked a little bit at the code and
the accel_startup worked as expected at the apache start
and ZCG(startup_ok) was equal to 1 at the end of it. I'm suspecting that my
problem is related to the fact that I'm using a multi-threaded environment.
Could it be because the startup_ok variable is in the zend_accel_globals
structure and not in the zend_accel_shared_globals ? And that a
new zend_accel_globals is created for my request where the startup_ok is
not 1 ?

If you have any idea of anything I could have done wrong please let me
know. Also if you need more informations just ask and I'll try to provide
them to you.

Thanks for the help !
Pierrick

On 13 February 2013 09:51, Zeev Suraski z...@zend.com wrote:

 For your browsing pleasure:



 https://github.com/zend-dev/ZendOptimizerPlus/



 An initial README with some instructions is available at
 http://bit.ly/VSs5KC

 We’ve put it under the PHP license, with the same PHP Group copyright
 header as all files in PHP.



 As per Derick’s idea, we can arrange a webinar for those interested in
 better understanding how it works.  Note that this will not be a webinar
 for the faint of heart – opcode caches are complicated pieces of software;
 Attendees should have very good engine-development knowledge to have a good
 chance of understanding what’s going on…  Stas – your help in that webinar
 would be very welcome J



 Zeev

Re: [PHP-DEV] Re: [VOTE] CURLFile uploading API

[Pierrick Charron]

Hi Stas,

I'm not against it but, just being curious, what are those security reasons
?

Thanks
Pierrick

On 28 January 2013 15:01, Stas Malyshev smalys...@sugarcrm.com wrote:

 Hi!

  I've started a vote on CURLFile RFC:
  https://wiki.php.net/rfc/curl-file-upload#vote
 
  Please vote.

 Looks like the feature has been approved almost anonymously, so I'll be
 proceeding with merging the pull soon. I'm also planning adding __wakeup
 there that blocks unserializing CURLFile, for security reasons, please
 tell me if anyone thinks it's not good. Also, if anyone has
 comments/suggestions/additions to it, you are welcome to voice them.

 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

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

Re: [PHP-DEV] Re: [VOTE] CURLFile uploading API

[Pierrick Charron]

Thanks for the example. Even if it's not frequent I agree that it doesn't
cost much to prevent this issue

Pierrick

On 1 February 2013 13:04, Stas Malyshev smalys...@sugarcrm.com wrote:

 Hi!

  I'm not against it but, just being curious, what are those security
  reasons ?

 If you ever accepted serialized data from outside (say, after putting it
 in a cookie or just having API that accepts serialization) and then
 forwarded the same data array using cURL, the attacker could create
 serialized representation of CURLFile that would make cURL send out a
 file on your filesystem, which would be a security breach. Basically the
 same security problem as with @, only with serialization involved. It is
 not frequent case, but possible.

 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading

[Pierrick Charron]

Hi Stas,

What's the status of this fix ?

Thanks
Pierrick

On 8 January 2013 04:23, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 Looks good to me, just it could be great to add a new cURL option at
 the same time to disable the '@' usage so that someone working with
 the new ext/curl version can disable it and therefore send values
 starting by @

 That is a good suggestion, I'll add CURL_SAFE_POSTFIELDS which would
 disable the @ option.

 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

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

Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading

[Pierrick Charron]

Great :) Thanks for the update

On 17 January 2013 15:35, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 What's the status of this fix ?

 The pull is in the RFC, so I planned to do the vote on Monday and then
 get it merged if nobody objects.
 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

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

Re: [PHP-DEV] - True Annotations

[Pierrick Charron]

Annotations can be nested so in this case [Foo([BAR])] there is a big
ambiguity and we can not determine if [BAR] is an array with the BAR
constant in it or an annotation.

Pierrick

On 9 January 2013 05:53, Clint Priest cpri...@zerocue.com wrote:
 In none of those scopes would [ ] be a parsing issue I believe...

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

Re: [PHP-DEV] - True Annotations

[Pierrick Charron]

# is an alternative syntax for comments

On 9 January 2013 08:27, Nikita Nefedov inefe...@gmail.com wrote:
 #Foo(#Bar())

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Pierrick Charron]

Hi,

I agree with you on this point, we should not introduce any new
feature if there is no way to deal with largely used extensions like
apc, xdebug or maybe others. The provided implementation is not
supposed to be final (syntax or internal implementation) and I'm sure
there are many improvements that could be made to make it better and
I'm open to any suggestions. If the implementation and the idea is
considered, I'll be please to work on a patch for APC so that
annotations can be cached and that there is as less performance
decrease as possible (it will at the same time give me the occasion to
look at APC internal). I'll probably need some help but I'm sure this
will not be an issue.

Pierrick

On 9 January 2013 11:35, Rasmus Lerdorf ras...@lerdorf.com wrote:
 In this case, attaching annotations/properties to classes will
 definitely affect APC since we cache classes separately and NOP their
 creation out of the op_arrays. So any extra opcodes will have to be
 optimized out and the resulting class created and cached correctly.

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Pierrick Charron]

On 8 January 2013 03:55, Stas Malyshev smalys...@sugarcrm.com wrote:
 On the contrary, plenty of implementations means there's a need in this
 functionality, and it might be a good idea to have one standard
 implementation if it can cover like 80% of use cases.

I agree, there is a need in this functionality, but all those userland
implementations were at the first place made because this
functionality was not part of the language. I think docblocks is not
the solution, doc blocks are just comments, and I would expect any
code to work the same way if I remove my comments.

Pierrick

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Pierrick Charron]

I do use PHP Unit and also Doctrine which uses annotations. And I know
that today because there is no native annotations, the implementation
use docblocks so I can not remove them :) But still if I did not know
anything about PHP and that someone was talking to me about comments,
I would expect my code to work even without them.

Pierrick

On 8 January 2013 13:28, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 I agree, there is a need in this functionality, but all those userland
 implementations were at the first place made because this
 functionality was not part of the language. I think docblocks is not
 the solution, doc blocks are just comments, and I would expect any
 code to work the same way if I remove my comments.

 So you never used PHPUnit and never will in the future, right? Maybe so,
 but thousands of other people do, and have no problem with directives in
 the comments. I think it is time to lay this red herring to rest -
 nobody who had any encounter with any of the most popular PHP tools
 really expects it.
 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

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