[PHP-DEV] PHP 5.6.39 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP
5.6.39. This is a security release. Several security bugs have been fixed
in this release. All PHP 5.6 users are encouraged to upgrade to this
version.

For source downloads of PHP 5.6.39 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.39

Please note that according to the PHP version support timelines(
http://php.net/supported-versions.php ), PHP 5.6.39 is the last scheduled
release of PHP 5.6 branch. There may be additional release if we discover
important security issues that warrant it, otherwise this release will be
the final one in the PHP 5.6 branch. If your PHP installation is based on
PHP 5.6, it may be a good time to start making the plans for the upgrade to
PHP 7.1, PHP 7.2 or PHP 7.3.

To verify the downloads, you can use the following information:

php-5.6.39.tar.bz2
SHA256 hash:
b3db2345f50c010b01fe041b4e0f66c5aa28eb325135136f153e18da01583ad5
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJcB7duAAoJEMK/C8Qzz8iz1ocH/2LHnP4frU5Lox2eaWCDCUY0
TnFJmEM6TOh8K0g7z3McsK1uDUCHdIYLEX10N1ruKDryvAXgl5Jp3nZDqbJIymtb
cbgQkLNeiPu0gsccPz/pR/vXWT7EzkPzWdkH8Ne01RJRxUZi9MFHwd80bToDGkPs
RU8ba96rlLu32iGMnRtvgjaLfnCWYWHH/fuObTy66ksRwe1mTtSMbXHGZ7t5fBy6
km7uapx14CAcadQeekwrOZdx/+6pTd0T9n0IU7d7oIr4fSqXErIH6RHH0YBDR/+a
6Jev0JleCxQjGY+rhPve/nAQxkDRx3/h1KMVrgIAP4ozPOIE/Ca+X6zbC9xS0Io=
=Yy6C
-END PGP SIGNATURE-

php-5.6.39.tar.gz
SHA256 hash:
127b122b7d6c7f3c211c0ffa554979370c3131196137404a51a391d8e2e9c7bb
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJcB7d3AAoJEMK/C8Qzz8izHUUH/iyPshr5U3EIaPcxsN22LOyn
7I3lYLdUhClRUNHNmSMyj3FmoIDavJQ++mrJ7L8RVlXzhbIjG4edSomcskXnjfKu
js3hFiuF6XmrzpfEc/iGnptHzltD4Ts0LiKRk1Dnm1D7R8Drk0jdIHdMAGeCgZH9
lN0TBPxTW7JZ4OE5Mc9I1UtBTGboSw2TASuIFrWtNiYFfnr/i8CmDu1u1TSmmbs+
3YHLBxF8k2RaYaX36F8E6gnvKEY12SzWlfS44A0XaVv9C+YfCQCVrRsqg+Pd0LBm
YOk0II4ATjS/jUvxnYNuqENbw64sOvh8qNKSNAoBohgi88EGqzcITZp4KuwzaJE=
=zTcm
-END PGP SIGNATURE-

php-5.6.39.tar.xz
SHA256 hash:
8147576001a832ff3d03cb2980caa2d6b584a10624f87ac459fcd3948c6e4a10
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJcB7d+AAoJEMK/C8Qzz8iz8e0H/1BwoQHUrEKXpdTEzqA/NsOA
d008nHnmBc6WkHB7JAbNCFOlmKuiNgSZMRb7sQBaszY7qGwDQ+K6LUysQ9FAyUA/
N0TjfITiqUoqnV3X1dOOLOfEBrVFlXp/spiqu5ywmhlUY6l2/3W8Jbg9/SfiwHYV
lEZHP4qDEiIUHD/q6MsTECt/VEm6YS4fN++quFEOmp+qwvHs1U9AU29Z5S84qVhf
07HfeDye2sEcdWXbwgMfksubLYgneZb3Lm9MnBcQ3T/RNZ8vUkBPdJ+pesY2sJJ6
TeX3z6aqbCqySliJ9qrgli1H8uxdAp53AFvdxKGGM2HFPjpFrPmsCZ6cijKTgxQ=
=24z1
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

[PHP-DEV] PHP 5.6.38 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.38.
This is a security release. One security bug have been fixed in this
release. All PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.38 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.38

To verify the downloads, you can use the following information:

php-5.6.38.tar.bz2
SHA256 hash:
d65b231bbdd63be4439ef5ced965cfd63e62983429dbd4dfcfb49981593ebc03
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJbmE+wAAoJEMK/C8Qzz8izZ7kH/3bONDgTi4jq4KHmRTfh3gNI
EoocCUR73dwoNP4GhBvTvpvnBDt71kGnd8t8LsEAT7DNagZOPbuBzc8mM3QM36Zo
cAgPQEfB399EgQ9nq+2phwk8v9Svso9eMEq392PZqUju5IgBKzN5CtjEu08BeBy9
dLx61PbDH7tzxdBNytNnnQkWDkLye8LH97Lw96Cx+kep+dn213VlDiTAeiRWmfvk
QZwoXe8j9J3YQ6hRaQ4dGOE27AAR6Lxs2+RWp09oxPqytt+wiqKTEaey4wd4v1Iw
sdOLyQNjCJKyvPuCnMCtLXPk8UeAIecKjOtjNO5v46Rl1gaBqBAeVpYY04vJ2Vg=
=Zjd/
-END PGP SIGNATURE-

php-5.6.38.tar.gz
SHA256 hash:
3b74d46cd79a45cce90c8059e09d8bd0beeb5de562cbb0cb42f96ff8fa665fd4
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJbmE+4AAoJEMK/C8Qzz8izxfkIALo108XYAlm1hp3y1mLYnmRO
SBVc9AYJkn3xY4VKr+LTok+nL7tC+3KLLVwOGvWPZb5lkVYKaP3CQASMh0+a/Fae
BIElEfkptNwerAkg28Lb9QnRhty0u3pSuU9lpRqnX1MT1/o/pVnGPdh5tvbgE2Hl
M2NXI/fSE+7c5aPM80nq3uVo0V/rJtl1AqtddtweFE1cJKhnG2BHojMg3EHLLe0o
dUl7TVSZTa8jB++0aIMPkUMB6AUG+fw1YigS+ya4vE/7W0BtUbuc3Lm8ihqFNNHP
5CrZYL09O222DLAEWX5ePoRQoL/hRhBWi+OqKEHp3ay1c7odC7HZUlmZdWC2tTc=
=uT4P
-END PGP SIGNATURE-

php-5.6.38.tar.xz
SHA256 hash:
c2fac47dc6316bd230f0ea91d8a5498af122fb6a3eb43f796c9ea5f59b04aa1e
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJbmE++AAoJEMK/C8Qzz8iz8MAH/0JuF4DIvvZ2kf89dWrdCdA7
wI3v5/6tldVJDhVTi0dJuOpnQsGeupGLdmdAyc5vHqaUInmgJgOlkNtplaHwEhkg
ULREEcnsxkfLymEwPrbiwPQUTSXSLmRIg+1iZqVnPEFZkuolazqeisYDJelUO8l8
rqYSWiDm/wLe04vsFbjw3cDPpwY8Kb3AvV4Oeg8Iplb7b80jlHmXqNj0/xUohsia
k/Bw8fqQgMq7ZYwRWpS530YP6t09Nx1bMNacVYU/HcjgoQzcZ/Q1p70nckLziFwK
UXrX0iIlfTx5cjIMbKZBykjiib16uIH5YJNO+hzZbfZgVNmjmMzlEVIsUkC91X0=
=g+1N
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

Re: [PHP-DEV] Status of ci.qa.php.net?

[Ferenc Kovacs]

On Mon, Aug 13, 2018 at 8:07 AM, Pedro Magalhães  wrote:

> On Fri, Aug 10, 2018 at 12:19 PM Christoph M. Becker 
> wrote:
>
>> On 01.08.2018 at 20:29, Pedro Magalhães wrote:
>> > If anyone finds some value in having something like this and wishes to
>> > revive our instance, I'd be glad to help setting it up. If we feel that
>> > Travis + Appveyor are enough, that's fine too :)
>>
>> Well, on further consideration it seems that having our own CI would be
>> nice, especially if we'd run further test suites or different
>> configurations there.  On the other hand, someone would actually to have
>> a look at the test results, and act on failing tests.  Any volunteers?
>>
>> --
>> Christoph M. Becker
>>
>
> I'd say that if we want this, then it should be integrated with github and
> be a third check (next to travis and appveyor). Depending on the stability,
> it could be a required or an optional check. This would be better than
> expecting someone to manually check it.
>
> Regards,
> Pedro
>

the integration part is the easiest ( all of the mainstream products are
supporting github and the pushing the build results ).
I think first we should figure out what do we want exactly, what is missing
from our current CI pipeline (more platforms, more resources, we want to be
able to log into the build environment for better debuging, etc.),
depending on the answers we can figure out if we want another SaaS offering
or to build our own and what product/tool do we want to use.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Status of ci.qa.php.net?

[Ferenc Kovacs]

On Thu, Jul 26, 2018 at 11:34 AM, Christoph M. Becker 
wrote:

> Hi!
>
>  refers to , but the latter
> appears to be unavailable.  It seems the site was about Jenkins CI – has
> it been superseeded by Travis and Appveyor?  If so, qa.php.net should be
> updated.
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hi,

it was mostly managed and used by me and at one point it went down and I
did not had the time to contact the provider and figure out what happened.
I'm fine with being removed or if you think that it would be useful we can
try bringing it back.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.33 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.33.
This is a security release. Several security bugs were fixed in this
release. All PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.33 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.33

To verify the downloads, you can use the following information:

php-5.6.33.tar.bz2
SHA256 hash:
07f696a9761dcd839e2045c95c3a4d2ffb52c54417477cca9d30a14975b831cc
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJaTCfVAAoJEMK/C8Qzz8izEKwH/AoTrnxvfSFX4jCxRAu2Bxr9
hrjRxTYNMDqe60kfcCMbZsLhkBLc/WEdoDf5D1aydKia0crq8yWOIPFk2L1UXeKW
O2me6iXLwM+xmhbsNT/2oWXLvlM8ZIrjQLSt5Bqfhr/woOj+pRuVel94SbxzwO5v
p6KL7S39NWFbT90Y73Sh6z5XX63FMGVtRC02fzWbgId0Feo2ihFDMVHx3P8z0ZLk
6pvMX8gg77t+rWb8Wca3cSuYRpOCibMQ/Do96Zpg1bfqA7ewD/Ttj8rbC02qARBQ
kGLnJa/0Ch79dRYqVbB2X4Y8hozOVf6yqhCC1CkERLIDAlfwHMvrS/wqPZrgNY0=
=fiFg
-END PGP SIGNATURE-

php-5.6.33.tar.gz
SHA256 hash:
bedfac81cfaa25961812a1aec458c4109411a14991b43a416343ffb830b8da6a
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJaTCfbAAoJEMK/C8Qzz8izxBEIAOvDfffiOwpyy/tp/tIAb08C
XxJYiM6H5ISGkjUVqkmabemoGrz2micTavUJ8qDS8b5zzo4ZY/FCslq3ENTqBhBh
9r5PAcgOKR6tJdoZTdjPt2V8S01h7iJKebKy1xG9j8BtW5V00E27guMnSFWpYGjF
pQYIFgi04BatMCcFV5/Lvv9PECByLQ4TCtFdi43/OfLV6AovIp9xFNRATWys78uL
DcOGG1+zuL87jF85txL3LF5fNVNmb1sPZB6VQqgos37nwLSIVM2j1akeh/kBzztx
BdK4XNLfGjG6xFaxt1zH143hgGWfUWBo9XQnpQg5vrqGbzHhm0DhXHqOdTHHMWM=
=QBu+
-END PGP SIGNATURE-

php-5.6.33.tar.xz
SHA256 hash:
9004995fdf55f111cd9020e8b8aff975df3d8d4191776c601a46988c375f3553
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJaTCfhAAoJEMK/C8Qzz8izviEH/1EZHwfsuQpbeL5xJOKtlkt5
UMxGuPbHMWHrE9sbNtfO0RTUmfhgwDvaceWGmc3B2jPYaZAuTOCNuVNhJptt06JX
BAhE1BR3TvraIpgP7MOM7uRLuN8VL3GX4jGOJJCn4VDNK3BVaJ+/XMCQo4KE8zbW
wf2fTBG7EfDBDEWa9j0HJ6dEqkrKw0SOdcm3RkqZ9CR+E8nRkQ/4CH8d+nylW1im
2W/C5s5vHxmccCjy7VQ1YGIGP59xBwD3bNEVrHuFigLK56e4hLtcJtm17gtrAgkB
nzHdcu+n9BfGD/B78kqiJZOGPe51IrzEi6DXHuiU6QwYAiomTofKPQZos4jcFF8=
=DfMM
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

[PHP-DEV] PHP 5.6.32 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.32.
This is a security release. Several security bugs were fixed in this
release. All PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.32 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.32

To verify the downloads, you can use the following information:

php-5.6.32.tar.bz2
SHA256 hash:
3ee44e7a5fa42b563652b3ea0d3487bc236fcc9e5ea74b583775cab867abcb51
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJZ7/OLAAoJEMK/C8Qzz8izlksIAO3NaFPfpuNBPh/yAUjVvNIl
4i/wQIA82SXqX+4iJOomGswFHz7APjF1T7s2794IHswz9PAOk9p6HR5tr49+fo9X
rUf/nqX/Jg2kn5MoJG8E8YOjpwSTz9pfMUPxXMrX1FMljBmk5nM8NHNW22bVSY2Y
jyHfjG430vqv9eX4RbhOZLbKAYJ8JBf8ZmGGzbqlkmhoRwOwK3q7tnsomcAXvFeV
1N7l5jBKcgp3mIdUrLSJKRbUm2IPN696hkAHUjQxaXyxvrsdm061W+mO7FrUSyYx
nW/hFBXQHgyZKzU4Jd2F2LN5sCgAzOEt9ENVZ+2ZWSBddjwUEjuFt9IShd00YBU=
=KTAY
-END PGP SIGNATURE-

php-5.6.32.tar.gz
SHA256 hash:
7bef1ae8cd633df5b9c5964262d276d2dc21acbfcd94022d1e2084d199315df4
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJZ7/ORAAoJEMK/C8Qzz8iz1tQIANo6AdyPX9y2oWf5mvsKQtrs
P9Zkp+1k2rsdhdwyKki1DLZyZrhm3UHYyMHgbcdsSqZeT9r2Ocgk0anlOLhGtFuE
gFVCBvasuHFhsa3VIM/FtbN2cZ5piXZDSqkZ2fCnwsZ6TvaDRxlqXuVzBjRBjPRh
W6/KIdikznuc94pt3uXpYjxjS6sCA+zvu3hEhZ4tjKyrYH1OZiYf9l6dP6a925eh
SLUkvpf/hSg3LF8J90yoVwfpqgRZza2K2gv4nRu1JLrTn2/IOQ4BlIkFzY7msA4K
4nWI+ZuxD+kFZa5BQKwgQpdwM8EHHuwxvaiNDo31aO1BoBSVHtYNfd4FNqBzQkg=
=9KnA
-END PGP SIGNATURE-

php-5.6.32.tar.xz
SHA256 hash:
8c2b4f721c7475fb9eabda2495209e91ea933082e6f34299d11cba88cd76e64b
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJZ7/OXAAoJEMK/C8Qzz8iziEwH/3agpFdr4OeUC14jMz4Yp3Qh
4SLchCO7FknMoVOgC7HP+qfXKD7Tr7roSNqXd3XDmEyvshfc6GEiwCr3tGJev+G9
+dSl9s5y04YyrHitMRmNiNQQV2xYtQtRvwDQDCQBCz6oG3o3OhgymleuIczgUbP2
2DY4iIwL5RicG/UAWiQHNCEhvk3ovAfGcklq940pIV2WR2NVp5mwwl/djG8x60i6
AbwMAOCGJRKjzS1gR6bHoViEgLIA50xRYb4AZrouDXfqLTnBjNm4/hIwfROuSWRf
JXv5CAk0dg4FoDnDmaHz/OOQcRaCQE9sua1OO5OhGXQc7XckaiSyg8orb15O1pg=
=TXT6
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

Re: [PHP-DEV] Parallelised run-tests.php (patch)

[Ferenc Kovacs]

On Tue, Oct 10, 2017 at 9:01 AM, Michael Wallner  wrote:

> Hi!
>
> On 08/10/17 05:47, Andrea Faulds wrote:> Hi there,
> >
> > Do you spend HOURS every day AGONISING over how long run-tests.php takes
> > to complete?
> Yes!
>
> >
> > Have you long since ABANDONED every test directory besides Zend/tests?
> >
> > Does it feel like your eight CPU cores are pointlessly WASTED by
> > single-threaded PHP test execution?
> Yes!
>
> >
> > Are you SADDENED every day at how high-quality the run-tests.php code
> > is, DREAMING of an even worse mess?
> >
> > Then I've got just the trick for you!
> Ha, welcome to the club! I'm glad someone else feels the need, too.
> https://github.com/php/php-src/compare/master...m6w6:parallel-run-tests
>
> But, I just noticed, you've been part of that discussion, too:
> https://externals.io/message/75308
>
> --
> Regards,
> Mike
>
>
>
>
thanks for keeping the tradition of calling out the new participant about
the previous attempt :D
https://externals.io/message/75308#75321


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] Re: [PHP-WEBMASTER] Subscribe Function Seems to be down for several days

[Ferenc Kovacs]

On Wed, Aug 16, 2017 at 6:25 PM, Hannes Magnusson <
hannes.magnus...@gmail.com> wrote:

>  how are you trying to subscribe?
>
> Are you submitting the http://php.net/mailing-lists.php form? In which
> case, which mirror are you looking at? Could you try another mirror?
> If that still doesn't work, try sending empty mail to
> -subscr...@lists.php.net
> (e.g. internals-subscr...@lists.php.net)
>
> If you are not using that form, but are sending the subscribe email,
> please forward the full original reply you get.
>
> -Hannes
>
>
> On Tue, Aug 15, 2017 at 9:40 AM, Alan Feuerbacher 
> wrote:
> > On 8/3/2017 9:06 AM, Andreas Heigl wrote:
> >>
> >> Seems like the mailinglist needs some love… again…
> >>
> >> Cheers
> >>
> >> Andreas
> >>
> >>
> >> Am 03.08.17 um 17:02 schrieb Alan Feuerbacher:
> >>>
> >>> I've been trying for several days to subscribe to a PHP mailing list,
> >>> but I keep getting the message "We were unable to subscribe you due to
> >>> some technical problems. Please try again later."
> >>>
> >>> Is there any way to fix this?
> >>>
> >
> > Hi,
> >
> > It has been close to two weeks since I emailed PHP about the mailing
> lists.
> > Has there been any activity getting it working again?
> >
> > Alan
>

hi,

I remember debugging this (mailing list subscription not working on
http://php.net/mailing-lists.php) and AFAIR I've debugged it back to the
our mailing infrastructure changes (I think the ecelerity -> postfix
migration) but couldn't solve it back then and then forgot about it.
I can look into this if nobody else beats me to it, but CC'ed Sascha as he
is probably the best person if this is indeed the problem.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] request access to wiki for rfc on samesite cookie implementation

[Ferenc Kovacs]

On Mon, Jul 10, 2017 at 10:50 AM, Frederik Bosch | Genkgo  wrote:

> LS,
>
> Hereby I am requesting karma to create a RFC for pull request
> https://github.com/php/php-src/pull/2613 on the implementation of same
> site cookies. This same site cookie is a proposed standard on protecting
> browsers/users against CSRF. The standard is adopted by Chrome and planned
> by Firefox (https://caniuse.com/#search=samesite). Major PHP frameworks
> already implemented this through a custom Set-Cookie header call. The RFC
> will try to convince voters that the samesite flag should be implemented as
> a language feature.
>
> Best regards,
> Frederik Bosch
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
hi,

I've granted you with rfc karma on the wiki

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Getting fd from stream

[Ferenc Kovacs]

On Sat, Jul 8, 2017 at 8:49 AM, Martijn van Duren 
wrote:

> On 07/08/17 00:47, Sara Golemon wrote:
> > On Fri, Jul 7, 2017 at 6:14 PM, Sara Golemon  wrote:
> >> On Fri, Jul 7, 2017 at 4:06 PM, Martijn van Duren
> >>  wrote:
> >>> blah blah blah
> >>>
> >> Ignoring the brokenness of your design, the original ask: Exposing the
> >> underlying FD from a file stream? Sure.  No particular objection to
> >> it, and the stream::set_option interface has the right mechanism to
> >> surface it in a general way.  Find someone to RFC it, and I don't see
> >> why it won't show up in PHP 7.3.  What you're able to do with it is
> >> your problem.
> >>
> > Here's a diff: https://github.com/php/php-src/compare/master...sgolemon:
> expose.fd
> >
> > -Sara
> >
> Thank you.
>
> As per https://wiki.php.net/rfc/howto I created the account martijn.
> I'd like the Karma to turn this patch into an RFC.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I've granted you with rfc karma on the wiki.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Getting fd from stream

[Ferenc Kovacs]

On Fri, Jul 7, 2017 at 10:14 PM, Martijn van Duren <p...@list.imperialat.at>
wrote:

> Hello Ferenc,
>
> On 07/07/17 19:49, Ferenc Kovacs wrote:
> >
> >
> > On Thu, Jul 6, 2017 at 11:12 AM, Martijn van Duren <
> p...@list.imperialat.at <mailto:p...@list.imperialat.at>> wrote:
> >
> > Hello internals@,
> >
> > I have an (exotic) case where I need to be able to get the
> > filedescriptor from a previously opened stream (via
> stream_socket_pair)
> > to hand over to the child process, which needs to reexecute.
> >
> > I saw that the php:// wrapper supports php://fd/X syntax, so I reckon
> > there should be a way to extract the information as well from a
> stream
> > as well. Unfortunately I don't seem to be able to find it.
> >
> > Can someone point me in the right direction?
> >
> > Sincerely,
> >
> > Martijn van Duren
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> > hi,
> >
> > would you need something like fildes_fileno() from
> https://github.com/Tyrael/php-fildes ?
> > I never managed to put that up for pecl, not sure if it even compiles
> anymore with recent php versions
> >
> Thanks for the hint, but I'd like to refrain from external
> libraries as much as I can, especially for something simple as
> a simple number inside a data structure.
>
> I might also achieve something like this by eio from pecl, through
> e.g. eio_dup2, but it's just unrealistic overkill to ask for a full
> extension installation for just 1 one trivial piece of functionality.
> >
> > --
> > Ferenc Kovács
> > @Tyr43l - http://tyrael.hu
>

sure, I just thought that you are asking for a solution and not proposing a
new feature/function to the core.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Getting fd from stream

[Ferenc Kovacs]

On Thu, Jul 6, 2017 at 11:12 AM, Martijn van Duren 
wrote:

> Hello internals@,
>
> I have an (exotic) case where I need to be able to get the
> filedescriptor from a previously opened stream (via stream_socket_pair)
> to hand over to the child process, which needs to reexecute.
>
> I saw that the php:// wrapper supports php://fd/X syntax, so I reckon
> there should be a way to extract the information as well from a stream
> as well. Unfortunately I don't seem to be able to find it.
>
> Can someone point me in the right direction?
>
> Sincerely,
>
> Martijn van Duren
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
hi,

would you need something like fildes_fileno() from
https://github.com/Tyrael/php-fildes ?
I never managed to put that up for pecl, not sure if it even compiles
anymore with recent php versions


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.31 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.31.
This is a security release. Several security bugs were fixed in this
release. All PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.31 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.31

To verify the downloads, you can use the following information:

php-5.6.31.tar.bz2
SHA256 hash:
8f397169cb65f0539f3bcb04060f97770d73e19074a37bd2c58b98ebf6ecb10f
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJZXX4+AAoJEMK/C8Qzz8iz2LsIAJ8zQLVLtAod1AJpsE71Ik6Y
XbVY8oglQq584d6NkHpImdEAZnK++W11mFxMYNAA8CI9keF44llKyZrBi/OM7XPV
bDt0rt/MeLCNr6uohx1ZgGQI28UIgKCc8H3H0fEvIFxxp0pEqQ900SS9ZZMU0cJS
QWHvcp00S2truxezDVGVOO63r+BTcg2AX87DpaYNcb10OYWgsGzdE4Ud8uqxI40+
0sPt77ulCG74Dznu5YH4BhVBLCHqwEjn2pGB/qxs6xDfoCyzjQO8U6oQ5VbFDkVk
W5tpRoKrCGbIMZes9DW+FU5Bpunr6so7JGm/8TqfzMX4M7/qVlrVrErdUrvyiYg=
=yP79
-END PGP SIGNATURE-


php-5.6.31.tar.gz
SHA256 hash:
6687ed2f09150b2ad6b3780ff89715891f83a9c331e69c90241ef699dec4c43f
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJZXX5FAAoJEMK/C8Qzz8izX0cH/2L5ysDRhlcqoCImyYUmwb1D
n6slSSVNYr6maYKwYk3NQlT5QvKjnUKEg+Z7EiLq+phyuf86ngaO8O/4UT3moJtk
Kmi2awG5NEhMw/BYjFGZtGYvf2gAjMuprn/zbVW2QXLiC1GY2qokn2C/TOEghduo
Vnj625XH7jc1SLmN9HVsOLL990KSdvpMz+wo/iPGyFlS9EEZn5qs3ohrP1jt4qfI
Jx4zjqSrCUwp5cA5cjjhRr36qBwwd6PqiAMuEeuzRkrzNAX9xqxwqMldP+njyhpM
EMwJbpdjKmdSbtLpm6X+/0fDgSGYaouR9bX6jaiTE5Tccd+RSUgXqMjBswsWyww=
=Yu+9
-END PGP SIGNATURE-


php-5.6.31.tar.xz
SHA256 hash:
c464af61240a9b7729fabe0314cdbdd5a000a4f0c9bd201f89f8628732fe4ae4
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJZXX5LAAoJEMK/C8Qzz8izt/QIAK27a0HrT19p9lpmRKc41rm4
W9nQ6i4eQU/VtPef5F6ZG0bheJWQz/k6XHOvQZ7aqhCW3ggwbr8Vfs0VKpGamIrV
TT/WH9bEYWdQiG0Jcf9I7XLGZs0GbqZw4qXYtJ7gG2NAqODsEpLkPRFgoLaH0sS1
sMdb74qUtjir4AVtCrhRpp9XpL2DDamXV6OpyAgZPM0NTsX4JTlrJh5HgOpr2mR1
/T9KI5R6jT7ndbX1X/1JWVnhqjLoG+WRijxzHTq1S7c68n5oj0LmQPHhfRn6jhkV
8Cuc96TPttwvKJ7Y+7z5DOiA3fHt9py/zQvgp9xT7TpV83OQ9MmdBbDT541MtLY=
=7uPl
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

Re: [PHP-DEV] PHP 7.2 Release Managers

[Ferenc Kovacs]

On Fri, Apr 7, 2017 at 5:47 PM, Sara Golemon  wrote:

> On Fri, Apr 7, 2017 at 3:20 AM, Remi Collet 
> wrote:
> > Le 07/04/2017 à 08:31, Davey Shafik a écrit :
> >> Thanks Remi!
> >>
> >> As the Release Process RFC requires two RMs[1], are you and Sara
> willing to
> >> collaborate as a team for 7.2? If not, you will each have to find a
> second
> >> team-mate :)
> >
> > From my side: Of course! ;)
> >
> > Remi
> >
> https://twitter.com/SaraMG/status/850222384787345413
>
> And by that I mean: Of course!
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
+1 for both of you, and personally I prefer to have 2 new RMs in addition
to the previous RM(s) mentoring.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.30 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.29.
Several security related issues were fixed in this release. All
PHP 5.6 users are encouraged to upgrade to this version.

According to our release calendar <http://php.net/supported-versions.php>,
this PHP 5.6 version is the last planned release that contains regular
bugfixes. All the consequent releases will contain only security-relevant
fixes, for the term of two years. PHP 5.6 users that need further bugfixes
are encouraged to upgrade to PHP 7.

For source downloads of PHP 5.6.30 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.30

To verify the downloads, you can use the following information:

php-5.6.30.tar.bz2
SHA256 hash:
a105c293fa1dbff118b5b0ca74029e6c461f8c78f49b337a2a98be9e32c27906
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYgBEpAAoJEMK/C8Qzz8izivcH/jCMwv13K9O+HGfWigZ8a4tC
nWfUuGRO0wsM4zvAbIJyZ3ZRLK9YOX6syJu/2fosXRUR3zk4dOcFvKjGqU4MEzGu
oiqsuNgGEcBx6O2PAuw5/N6IXIpnbT8BsS/uGlfGBM+cmkmXppvUisgR3TmqPYFC
zX0uncfvAYzJ7JKPtg9aS8MYgqlN6K1xjR7QaIA7wYVIlGYFoQZLpACgoJOrwmhP
y2WivBl/Fjnz+B6a1x/xakREnfaFj+1HJBPHWYFECm+DTNDoP4oQFt1xClAGLVzK
cVagAeWdtL91tEtSE66h82Ib1N6Bc427HyIMWtR0ymKminlbNsO2EYi9RhorgAw=
=rxwH
-END PGP SIGNATURE-


php-5.6.30.tar.gz
SHA256 hash:
8bc7d93e4c840df11e3d9855dcad15c1b7134e8acf0cf3b90b932baea2d0bde2
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYgBEvAAoJEMK/C8Qzz8izu/8H/ArqFUZw5lgqdy46JeltOVm7
KhfSc8avloCgQTv59ZrK1vB7sWnCGSB6aWILI1HGsrkHz9CG/X0HvMQbi058ERx9
qwsbr8vt5d/jQwPgdl1Uu+phLnYERk4ltotPRF7c9ZEt8aNDvTZ8RhYCVW+safdA
B5JcmaQtHpu2xDjfedXYPmFXe4Sc+NJb+Jb4yaHLVMquqofT+W8H7xOrK0EBYens
+aGDRTdAj+9Qxuk1N2HdXegFqyZ0dkAqFN3pGCF1vZcXHZQFY2IVJOI3FHsn9Mih
VCDvyG7WNtfKsPRvnlGrJKSOaGGC7wVYRo5tRMHk59fzQfSeCdbNXHDPx54JDXs=
=pZ1d
-END PGP SIGNATURE-


php-5.6.30.tar.xz
SHA256 hash:
a363185c786432f75e3c7ff956b49c3369c3f6906a6b10459f8d1ddc22f70805
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYgBE1AAoJEMK/C8Qzz8izdfoIAIRPbh381zxjedUGUHalJed8
6L0bgonmAAwzVtUMHcnTa2JzW6fb1KOICdhXxTInAcrD3GM4AOJbddgWZwIpb0gF
fdv2UH81E8PEEZd3gMgrJuhaKoTmxaGUFVZy5kbYNGcgfbjWi+MVY7mqmDGIKb6g
+I4wg1xB7ANEpR+RSitQcnBjKTnmNOvnw/vnvcmrDqfhjsW/xgFeYRzt36tC0ecy
TorBDOLlKxpkAQSE+BqsIeLvQykmm2dwJICtPZG7QTv4udrcUGooiXGKemKx747R
UrrsqG832IyzbykXk87bN+QiqmBib/hHNVNtvzsYFNsd+Y/+hT8t+mnc2d3f6gs=
=2U7f
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

Re: [PHP-DEV] bugsnet cleanup

[Ferenc Kovacs]

On Sun, Jan 8, 2017 at 7:46 AM, Joe Watkins  wrote:

> Morning internals,
>
> Some of you may have noticed that a few of us have put considerable effort
> into cleanup of pull requests on github, these are now manageable and I'm
> quite confident that we will be able to merge pull requests in a timely
> manner, and stay on top of it.
>
> When it comes to bugsnet, there are feature requests and bugs that have
> been open for more than 10 years, and nobody has talked about them in about
> as long, they may concern defunct versions of PHP, or removed extensions or
> SAPIs: These numbers in the thousands.
>
> It's very difficult (impossible) to see a good reason for these to be open,
> they are not useful at all.
>
> With normal support for 5 ended, now is the perfect time to cleanup
> bugsnet. If we can get the numbers down to something manageable, we have a
> reasonable expectation to stay on top of them.
>
> I think anyone that has been waiting a number of years for a response to a
> feature request deserves to know that it is not reasonably happening, and
> that there are better ways of trying to get a feature in than opening
> yet-another-feature-request on bugsnet.
>
> I think any bug report opened against 4 and not updated is useless.
>
> I think anything with a patch attached targeting 5 is useless, regardless
> of age; they should be encouraged to open a pull request on github against
> a supported branch.
>
> I'd like to hear what others think about cleaning up bugsnet, what criteria
> we might use for a mass cleanup.
>
> After a mass cleanup, I/we will go in and start working through whatever is
> left, but 5k mostly irrelevant bugs is too much to ask, it would take me
> months and months to work through those, time that nobody has, or will ever
> have.
>
> Cheers
> Joe
>

hi Joe,

thanks for triaging the github PRs, I also agree that we should do some
culling on our bugsweb issues (relevant: https://www.
joelonsoftware.com/2012/07/09/software-inventory/ ).
just wanted to mention that we have the feedback status, if a bug stays in
the feedback status for 2 weeks the bug will be closed by a cronjob with
the no feedback reason.
we could set the old bugs to feedback with an automatic comment that please
review the issue and target a supported version if you still want this
issue to be resolved and then let the reporters do that or the bug will be
closed.
I think this is a good compromise between just closing/suspending the
issues without explanation.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] force push in php-src

[Ferenc Kovacs]

hi,

we had a wrong merge in the php-src, merging master into PHP-7.1. I've just
force pushed the last good version before the bogus merge(
6fbd61a8199fbac9aac25d0dfaf1402a8f2b4e7b). You can find the bogus state at
https://github.com/Tyrael/php-src/tree/7.1.0-broken if you happen to have
some commits which you still want to have in PHP-7.1.

In case you *pulled* between that wrong merge and the fix git will
reject doing a fast forward merge in that case please put your local 7.1
(and master accordingly) branch aside and reset to upstream, then cherry
pick local changes.

This might be an approach:

   $ git checkout PHP-7.1# Go to your local 7.1 branch
   $ git pull# Results in error "can't fast-forward"
   $ git branch backup-7.1   # create a backup
   $ git reset --hard origin/PHP-7.1
 # Overwrite local 7.1 with upstream
   $ gitk PHP-7.1 backup-7.1 # Investigate changes, cherry pick etc.
   $ git branch -D backup-7.1# Remove backup (warning: no
 # confirmation before deletion, be sure
 # there's none of your work left!)

Re: [PHP-DEV] Re: Mailing Lists and URLs Causing Rejections

[Ferenc Kovacs]

On Tue, Jan 10, 2017 at 9:22 AM, Sara Golemon <poll...@php.net> wrote:

> On Mon, Jan 9, 2017 at 11:56 PM, Ferenc Kovacs <tyr...@gmail.com> wrote:
> > On Tue, Jan 10, 2017 at 4:21 AM, Ferenc Kovacs <tyr...@gmail.com> wrote:
> >> yeah, unfortunatelly ecelerity is a bit of a black box, here is the
> >> relevant config:
> >>
> If only someone on systems@ knew anything about ecelerity...
>
> Wez, have you ever heard of this ecelery thing?
>
> -Sara
>

obviously he was the only person who truly understood it.
but he isn't around nowdays, hope you can reach him and if he still
remembers it now that he moved on from Message Systems

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] Re: Mailing Lists and URLs Causing Rejections

[Ferenc Kovacs]

On Tue, Jan 10, 2017 at 4:21 AM, Ferenc Kovacs <tyr...@gmail.com> wrote:

> I've spent some time yesterday and tonight with the ecelerity config, here
> are my results:
>
> On Tue, Jan 10, 2017 at 2:06 AM, Davey Shafik <da...@php.net> wrote:
>
>> Ferenc,
>>
>> As you can see below, the issue is even caused when the email has _zero_
>> URLs such as the one you replied to, which was also rejected.
>>
>
> yeah, unfortunatelly ecelerity is a bit of a black box, here is the
> relevant config:
>
> Validate validate/omniti_tools url_ripper {
>   base="sbl-xbl.spamhaus.org"
>   max_lookups = 100
>   forward = true
>   bits [
> 0.0.0.2 = "sbl_hits"
> 0.0.0.4 = "xbl_hits"
>   ]
>   address_headers = "Errors-To:From:Reply-To:Return-Path:Sender"
> }
>
> we don't know what does the url_ripper function do, exactly, my guess is
> that it fetches the links from the message body, and I also guess that the
> headers listed in address_headers will also searched for domains/ip
> addresses, and all of those will be matched against the
> sbl-xbl.spamhaus.org blacklists.
> the bit field controls what labels will be set for the given mail based on
> the response from sbl-xbl, and there are future rules later in the config
> which will trigger when those labels are set.
> as far as I can tell the following rull will be hit eventually which will
> stop the processing of the mail and fail the delivery:
>
> if not vctx :is "can_relay" "" {
> if not vctx :is ["connect-wl", "mailfrom-wl", "rcptto-wl", "user-wl"]
> "match" {
>
> # Other rules
>
>   if anyof(
> vctx :contains "sbl_hits" "",
> vctx :contains "xbl_hits" ""
> #vctx :contains "sc_surbl_hits" "",
> #vctx :contains "ws_surbl_hits" "",
> #vctx :contains "ph_surbl_hits" "",
> #vctx :contains "ob_surbl_hits" "",
> #vctx :contains "ab_surbl_hits" "",
> #vctx :contains "jp_surbl_hits" ""
> ) {
>
> if vctx_conn :is "p_esmtp" "true" {
>   ec_tarpit 40 "spam tarpit";
> }
>   ec_action 550 text:
> 5.7.1 mail rejected by policy.  SURBL hit
> Spammy URLs in your message
> See http://master.php.net/mail/why.php?why=SURBL
> .
>   "spam:Spammy URLs in message";
>   stop;
>   }
> }
> }
>
> I was able to pinpoint that the sbl_hits label will be set for the false
> positives, and for now commented out this rule, but couldn't figure out
> what exactly triggers the sbl_hits label for these seemingly ok emails.
> (and of course our custom config is fairly comples, there are no available
> documentation anymore for ecelerity and it is a closed source product)
>
>
>>
>> Also, it was mentioned recently that we had moved away from ecelerity as
>> our MTA, but this indicates we are still using it for lists? If not, then
>> the change you made will likely not solve anything.
>>
>
> ecelerity is still used on the lists.php.net (pb1.php.net) box, it was
> only replaced for the php.net MX (which is now managed via a postfix
> install on php-smtp2.php.net) which was also running ecelerity in the past
>
>
this did not help (the sbl_hits was caught by another rule eventually), so
for now I've commented out the sbl_hits like from the validation block, so
basically disabled the primary spam filter until we figure out and fix the
problem properly.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] Re: Spam protection: false positives

[Ferenc Kovacs]

On Fri, Jan 6, 2017 at 7:34 PM, Ferenc Kovacs <tyr...@gmail.com> wrote:

>
>
> On Fri, Jan 6, 2017 at 6:39 PM, Christoph M. Becker <cmbecke...@gmx.de>
> wrote:
>
>> On 23.12.2016 at 23:48, Christoph M. Becker wrote:
>>
>> > On 23.12.2016 at 22:41, Andrea Faulds wrote:
>> >
>> >> Andrea Faulds wrote:
>> >>
>> >>> Is my website in my signature illegal? SURBL doesn't blacklist it, yet
>> >>> the news server rejected a previous email containing it and one other
>> >>> domain.
>> >>>
>> >>> If this email gets through, the answer is "no".
>> >>
>> >> Is mentioning the wiki in an email body illegal? SURBL doesn't
>> blacklist
>> >> it, yet the news server rejected a previous email containing it along
>> >> with my domain.
>> >>
>> >> I tried sending a follow-up test email with
>> >>
>> >> https colon slash slash wiki dot php dot net slash rfc slash
>> >> on_demand_name_mangling
>> >>
>> >> It did not get through.
>> >>
>> >> So, wiki dot php dot net is the issue, I guess.
>> >
>> > I'm afraid that all of php dot net is rejected currently. :-(
>>
>> Apparently, this issue has been solved.  Testing: <https://wiki.php.net/
>> >.
>>
>> --
>> Christoph M. Becker
>>
>
> I've restarted ecelerity on lists.php.net after I wasn't able to send out
> the 5.6.30RC1 announcement emails.
> I'm not sure if that was the direct cause of the resolution or just a
> coincidence.
> I've looked into my emails and they were rejected by ecelerity with
> sbl_hits=1, I've looked into our ecelerity config and here is the relevant
> part:
>
> Validate validate/omniti_tools url_ripper {
>   base="sbl-xbl.spamhaus.org"
>   max_lookups = 100
>   forward = true
>   bits [
> 0.0.0.2 = "sbl_hits"
> 0.0.0.4 = "xbl_hits"
>   ]
>   address_headers = "Errors-To:From:Reply-To:Return-Path:Sender"
> }
>
>
>   if anyof(
> vctx :contains "sbl_hits" "",
> vctx :contains "xbl_hits" ""
> #vctx :contains "sc_surbl_hits" "",
> #vctx :contains "ws_surbl_hits" "",
> #vctx :contains "ph_surbl_hits" "",
> #vctx :contains "ob_surbl_hits" "",
> #vctx :contains "ab_surbl_hits" "",
> #vctx :contains "jp_surbl_hits" ""
> ) {
>
> if vctx_conn :is "p_esmtp" "true" {
>   ec_tarpit 40 "spam tarpit";
> }
>   ec_action 550 text:
> 5.7.1 mail rejected by policy.  SURBL hit
> Spammy URLs in your message
> See http://master.php.net/mail/why.php?why=SURBL
> .
>   "spam:Spammy URLs in message";
>   stop;
>   }
>
> unfortunatelly the validate/omniti_tools is a shared object which has an
> exposed url_ripper function, but there is no available sourcecode or even
> documentation what I could find, so I have no idea what does that exactly
> do (I'm assuming it uses the sbl-xbl.spamhaus.org dns interface, but I
> don't know how exactly it fetches the links from the message), and couldn't
> find any of the domains mentioned in my email body on (php.net and
> github.com) on the blacklist.
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>

and I wanted to mention that we should really-really move away from
ecelerity it is a closed source product, which we have an old unsupported
version on lists.php.net (from the version number it seems it can be even a
custom built one by wez) and nobody else but Wez is familiar with it, who
is rarely around the php project anymore, so would be nice replacing this
one with postfix as we(Sascha mostly) did it for the php.net MX
-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] Re: Spam protection: false positives

[Ferenc Kovacs]

On Fri, Jan 6, 2017 at 6:39 PM, Christoph M. Becker 
wrote:

> On 23.12.2016 at 23:48, Christoph M. Becker wrote:
>
> > On 23.12.2016 at 22:41, Andrea Faulds wrote:
> >
> >> Andrea Faulds wrote:
> >>
> >>> Is my website in my signature illegal? SURBL doesn't blacklist it, yet
> >>> the news server rejected a previous email containing it and one other
> >>> domain.
> >>>
> >>> If this email gets through, the answer is "no".
> >>
> >> Is mentioning the wiki in an email body illegal? SURBL doesn't blacklist
> >> it, yet the news server rejected a previous email containing it along
> >> with my domain.
> >>
> >> I tried sending a follow-up test email with
> >>
> >> https colon slash slash wiki dot php dot net slash rfc slash
> >> on_demand_name_mangling
> >>
> >> It did not get through.
> >>
> >> So, wiki dot php dot net is the issue, I guess.
> >
> > I'm afraid that all of php dot net is rejected currently. :-(
>
> Apparently, this issue has been solved.  Testing: .
>
> --
> Christoph M. Becker
>

I've restarted ecelerity on lists.php.net after I wasn't able to send out
the 5.6.30RC1 announcement emails.
I'm not sure if that was the direct cause of the resolution or just a
coincidence.
I've looked into my emails and they were rejected by ecelerity with
sbl_hits=1, I've looked into our ecelerity config and here is the relevant
part:

Validate validate/omniti_tools url_ripper {
  base="sbl-xbl.spamhaus.org"
  max_lookups = 100
  forward = true
  bits [
0.0.0.2 = "sbl_hits"
0.0.0.4 = "xbl_hits"
  ]
  address_headers = "Errors-To:From:Reply-To:Return-Path:Sender"
}


  if anyof(
vctx :contains "sbl_hits" "",
vctx :contains "xbl_hits" ""
#vctx :contains "sc_surbl_hits" "",
#vctx :contains "ws_surbl_hits" "",
#vctx :contains "ph_surbl_hits" "",
#vctx :contains "ob_surbl_hits" "",
#vctx :contains "ab_surbl_hits" "",
#vctx :contains "jp_surbl_hits" ""
) {

if vctx_conn :is "p_esmtp" "true" {
  ec_tarpit 40 "spam tarpit";
}
  ec_action 550 text:
5.7.1 mail rejected by policy.  SURBL hit
Spammy URLs in your message
See http://master.php.net/mail/why.php?why=SURBL
.
  "spam:Spammy URLs in message";
  stop;
  }

unfortunatelly the validate/omniti_tools is a shared object which has an
exposed url_ripper function, but there is no available sourcecode or even
documentation what I could find, so I have no idea what does that exactly
do (I'm assuming it uses the sbl-xbl.spamhaus.org dns interface, but I
don't know how exactly it fetches the links from the message), and couldn't
find any of the domains mentioned in my email body on (php.net and
github.com) on the blacklist.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.30 RC1 is available for testing

[Ferenc Kovacs]

Hello everyone,

PHP 5.6.30 RC1 was just released and can be downloaded from:

http://downloads.php.net/~tyrael/

The Windows binaries are available at http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-5.6.30RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for Jan 19th, if no critical issues will
be discovered in the RC.

In case you think that other projects should also receive this kind
of emails, please let us know privately, and we will add them to the
list of projects to contact.

To verify the downloads, you can use the following information:

php-5.6.30RC1.tar.bz2
SHA256 hash:
c8c6b378685d7051686364e3b5f15be1dd0804616171fa1f7be3866948a30628
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYb1isAAoJEMK/C8Qzz8izFW8H/2c4dLl3xhac1uKYtZwBpuiC
4VHS5DS55EMlURCJonxYbcdnBaOJmmKtc/T4ZYTO2OOe/Ku3j7toVJF8y+eG7dsU
38zDxsCIfCfPb0dNQf8+rxKFECUOsjM64RMO/vg4dm+B4is9abHErs/w58lCyOYy
q4eEZOwT2NNMkRDcK88dRR3Ee+IW3GtZPHBqoGOplHIgemy4ejO7m870C/uuQQAG
r6hLt2IJQuIkxMcan1W8r7Rmon5W1lZm1QIZqxSyprm4arPthmEk7vCpuG9GxFMQ
g4qrpPok6aAvgcdZ7RKFmaQQU6AT1stO6Gu/S0rxWxhkh+1f6JKvVc/Mwcw4m50=
=qVUi
-END PGP SIGNATURE-


php-5.6.30RC1.tar.gz
SHA256 hash:
c848b3b0dcb811a824ea8169cdfa2b9cf7736be3f92eae3f6ad1a1e0efcd194b
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYb1iyAAoJEMK/C8Qzz8izXWUIAL4RS2kfM4dfv9PJMznGJd6w
b3ueiblLAdSpFhPjk/vfb6MNKamyahEtPg97LOndiAqldghfEBYtfWkeieEZZuZk
pthcmnCe2sIpIWYuzPEOqUE7PUmRd5xGhH6Z2KE6JJtYinzwYtlPbJRN7CR3cCw2
80fnu9O82P9qYwMSOnbcm0de3oiONvXrcVRHh5axqmEB9www6eR7sJ6/PGwsO27Q
6TCpt5JFSbayQ9OAPq56TJtwZNBACZ6DsuOBza2eFgCtLClvObH0BN4HR+Vz4xFI
/E29EJtCfnq5tamGO3pVhrzg2RNIEHN8xFCo32z8WPavdQhWef9PitRd5YQRC6c=
=m+Jv
-END PGP SIGNATURE-


php-5.6.30RC1.tar.xz
SHA256 hash:
7950bacb586152ddf4a054d86d1a926e9acc80148658c5eef84cce36fe74016e
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYb1i4AAoJEMK/C8Qzz8izsisIAM1heoowdhP6HBwDusSkrxpI
Pdngu2Ab34Q4LssVNNwOkr3Jg6o5Pvp6tX3swD+i1IcupgmdmM/KAalGmT+z8yqL
5tLRS42iboUfY8ZdvjKgv+wBqGdiawGYRvlKjTFWoqM0Zf+E9JBq3HzrnVYEek8N
ZDsKgVe+fdXKIIf27HfnoqieuUDVfy6f6FU/6OMvRl6TNZyCVXxYWi7zlxW6m4XS
9t8Rep1e/DZ2sySKazx7TidknFKkx/h9H/oqyXH+lgQnOHfxbBEfj0fIxEn2STOe
17wHM7NAVvzA7Jqd8nfHYFL+RqMl4aE08bfLMTjpE8KYNa9EmDSWE+W9qREtzvg=
=EK1u
-END PGP SIGNATURE-

Thank you for your support.

Ferenc Kovacs & Julien Pauli

Re: [PHP-DEV] PHP 5.6 end of active support

[Ferenc Kovacs]

On Wed, Dec 14, 2016 at 2:05 PM, Niklas Keller  wrote:

> 2016-12-14 12:23 GMT+01:00 Christoph M. Becker :
>
>> Hi!
>>
>> The end of active support for PHP 5.6 is documented to be on December,
>> 31th[1].  Does that mean that there'll be no further release with
>> "normal" bug fixes (but only security fixes)?
>>
>> [1] 
>>
>
> It has support until the end of the year, so I guess there will be one
> more release with regular fixes in early January.
>
> Regards, Niklas
>

yep, that's my plan, and the PHP-5.6 branch will be closed for regular
bugfixes after tagging 5.6.30RC1:
http://git.php.net/?p=karma.git;a=blob;f=hooks/pre-receive;h=fdff955c6b13c434aab40cb35cf002ab7c7eb146;hb=HEAD#l32
from that point on only RMs can push changes to the PHP-5.6 branch.
going into extended support also means that there won't be RCs as we don't
have regular bugfixes and we won't have a release each month, only when
there are security fixes ready to be released for 5.6

[PHP-DEV] Re: [PECL-DEV] Intention to move mcrypt to PECL

[Ferenc Kovacs]

On Wed, Oct 19, 2016 at 7:44 PM, Leigh  wrote:

>
> On Wed, 5 Oct 2016 at 20:11 Derick Rethans  wrote:
>
>> It should be migrated properly, and also to GIT.
>>
>
> Hi Ferenc,
>
> Can you create a php.net hosted git repository for this (I guess under
> the pecl/security namespace), and grant karma to le...@php.net for it.
>
> Sorry for picking on you personally. I don't know who else can do this :)
>
> Cheers,
>
> Leigh.
>
>
>

Hi,

I've just created the http://git.php.net/?p=pecl/encryption/mcrypt.git
repository (I think encryption was a better category as we already have
scrypt, libsodium and mcrypt_filter there).
Leigh already had karma for pecl/*, let me know if you need help with
creating the package or importing the source to the repo (
https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/
if you want to keep the history).

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.29 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.29.
Several security related issues were fixed in this release. All
PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.29 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.29

To verify the downloads, you can use the following information:

php-5.6.29.tar.bz2
SHA256 hash:
499b844c8aa7be064c111692e51a093ba94e54d2d9abb01e70ea76183a1825bb
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYSP77AAoJEMK/C8Qzz8izoAAH/2fKk7vVzWhKe0d+CDhOVZjo
qym/L4dsluDBE+onmOu9cCXXRU44xwd7Rvpv+1LQhpD+Pd4rWnVtWXH78Ro+k/Xl
BWh5vxefCosLY+Y3BgwRScEuyjS4TlTwJJaavQbiYydmPK9WSophx54iyeiAtvVZ
YRu2XeGkQb4lVirfawbTHbe9kcdkIvvE2uUz7Xq+oW9RL93ZZlQ0kc4S7qZGsUHx
HE8rP6dbaLpL4v0w0E3dFGQ6uEc/vTSx0tcY98bNwuS1reefq3fB3X9re7cet5O/
TxIz/I32S3LR3Egx5mivX3/4i1jmRbzuR/yoNphG2sjylUDhHFXVMJ/wbBrOhLM=
=/d5D
-END PGP SIGNATURE-


php-5.6.29.tar.gz
SHA256 hash:
0b1b939129a7286c5a474ac2cf845b979477f26dff36639e04022def9e252574
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYSP7zAAoJEMK/C8Qzz8izkbAH/1/6Lkl60b8mrfPQw8VMNzAP
+v2PWmfDqAhONO1a4AKxotxveZHjI/7/AfmbnADgnabGIJ9scFQ9vePO29Bwgb7H
r/b/4TrxzuaU3Tj8JJD7yabqmW05rwbc2llJ97qJ9um5PNX0Icve+D+LaXY4AN4p
ZVA3NjMOmZw8NigNAIkCq19oHAK1oxoWgPymrWOmzrNF+vXV4siej7F1MICAGAMr
EsFomdw9uxHyh3bTwqvmoOmuTDwVCgmaoYcK8HeCp2kut41j+uoUzc1OYkQZWavl
2pMoZLbrFY5rD1ReeiDBi7MTaXe1crOlS/epaAyzWbAWY53TuoN/g1Jgsq52l9c=
=vAGW
-END PGP SIGNATURE-


php-5.6.29.tar.xz
SHA256 hash:
0ff352a433f73e2c82b0d5b283b600402518569bf72a74e247f356dacbf322a7
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYSP8AAAoJEMK/C8Qzz8izUkIH/37hq4QmRh7pFJ0KNLrUJ9Zr
HhPzE50Qpn9KLsh3TeN8xzx6VBOvfRgmHClrwO7RZHNpx2TQlIbdP7JalYe31Utb
gaLcIoN1Kf8cJpcUD4y483uy3MRQGlGCBM3klTi4j0WaqJnnmXyheN++KPGPBTza
sI/Hom52pRuCrpkJfi3i9camihaP41IK47QXGa2BQ0F5AaDbE77BGXcg4SPInaOF
850Q7gmGzJY/QOnWbcMmjtt8go9muupU9A6tEDi8FrHNeS2ZCQX1qfEiUGK0cvpd
EIzvcIouBRcT4goDYIuVppZELQAWq/oemdXYrymvvHP/VepiQDLZxn4oAXU9ED8=
=HEZd
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

[PHP-DEV] PHP 5.6.29 RC1 is available for testing

[Ferenc Kovacs]

Hello everyone,

PHP 5.6.29 RC1 was just released and can be downloaded from:

http://downloads.php.net/~tyrael/

The Windows binaries are available at http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-5.6.29RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for Dec 8th, if no critical issues will
be discovered in the RC.

In case you think that other projects should also receive this kind
of emails, please let us know privately, and we will add them to the
list of projects to contact.

To verify the downloads, you can use the following information:

php-5.6.29RC1.tar.bz2
SHA256 hash:
226c4c941463b466fbc8e47903c83ac7a773712e72b40671f35e67d422b94bc7
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYN39MAAoJEMK/C8Qzz8izRfQH/1gyf7+iVrAQetZY8Hd3tEQj
vpi+43VaeTe0SRUJ/tMqoMhnPXhVQZz94tIEkyW+V/P89Zy4Cvlz4VfpqWWrwVtF
EwPfTpcXiO021Mx9p2DMS1iY8V1hLAoEMi0LkbkeOx0FYCsAGyUZrEZ2d30PYRgc
chcyzfLXxm0T5kMA2UgMKFl+HNCj8jG3wlUy9BY6IMTDBWHB70Juw6Vdza2WXimI
7sFc8FcfHJrt6rs3xJtH5HGowiREsMeHtDIvRpNYq5EOt4mJ+SS5O8msv88i7bwU
4TBLXRSZfPL09ZfYScA69lAS7umWjRBU3BqBFUN/tVixNRrfrWyHoiyyzaNRxH8=
=mULT
-END PGP SIGNATURE-


php-5.6.29RC1.tar.gz
SHA256 hash:
1b632130cb0300d77f415e27fe0e0e40737774a0ae6f29e294c5de2496d17ff0
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYN39UAAoJEMK/C8Qzz8izumUH/j45BXslgrFzzN38zpxGlfEx
Dsyl4LFDjwrVLJmddYPE5F/Nzv+cZhM8vG1KJCt+pcHjZfmTJMc44E3qqoHq4R1W
ROFHFqTOH5aafB+liqwi/WPCw/hKXngakkRR5DnUhbVaArdiCrGz6wem2Tf/Lr+7
WKmT5k89a4ONCehtcEzpO/byqTrlpCP7epej8YRbCpHBEoZwkunJJSrzLHcrFed8
mfvXGBMKMS9c6WBDcUZEld5J26pYisCydX7rs6OcGcmY6d1xHzueEBPDQk8MznGV
T0GgeSNHQN6wvzz+13fzo4ZUWtCzUbFhO92fQP0bJu+amZG3OO5UG9wIPLLpt/U=
=xG/W
-END PGP SIGNATURE-


php-5.6.29RC1.tar.xz
SHA256 hash:
4d3bf0a32bb739cfe6408aab56e46c80f138a0b473c491ef9b7d79bd4321616a
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYN39bAAoJEMK/C8Qzz8iz3hkIAKnkme4avtZiXjesXRuDzlN/
hyTpCQBp3l/7kWAZ7nSRS4Paj+TbOLLJabInCoZ5DPHd63AZwHqUV2YeLpA/+7WC
D/G/Jn4wzsfAaVBVKfIwKSK0GyXhQuhGYz8pD+xyCyezrQH/diCdX7nvNSJyE3JF
zU6TNmXP5NxtxQXBCbi542UGHHujdhJ/1wQmieUD3VvLAJ3AMvncvHJsLjVTd31p
BWksyE64FYTIaCDV9myGX0b3iL2DbPmGrGT/XSiuQeGbTbhUK0o6F87jJgWCZGLe
dhZ+aa6NhSQlMk5Nv/rYg49z72S4/zj4M/gmj/GhGb/6VsL33MWkz6mMUo1LJuM=
=dryq
-END PGP SIGNATURE-

Thank you for your support.

Ferenc Kovacs & Julien Pauli

Re: [PHP-DEV] PHP 7.1.0 GA

[Ferenc Kovacs]

On Tue, Nov 22, 2016 at 7:36 PM, Joe Watkins  wrote:

> Evening internals,
>
> I'm excited to announce that PHP 7.1.0 will be GA on December 1st.
>
> It has taken a lot of hard work from a lot of people, so stop whatever you
> are doing and give those people a round of applause.
>
> Cheers
> Joe
>

congrats, great job!

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Request for wiki account activation

[Ferenc Kovacs]

On Sat, Nov 19, 2016 at 5:10 PM, Net Mo  wrote:

> Hi PHP!
>
> I'm willing to write some awesome RFCs to make PHP great again, I'll build
> a wall and it'll be tremendous. Very very great. :-P
>
> But I'll start with something simple first :-P it is about improving
> ArrayIterator (you can find a draft here
> https://gist.github.com/Netmosfera/200c5e923f34cbc00cdb31224d730de8)
>
> I'm a Room11 regular and a PHP zealot.
>
> My wiki username is: WesNetmo
>
> Thank you!
>

hi,

I've granted you rfc karma on the wiki

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Limited access to php_version.h [Fwd: [PHP-CVS] svn: /SVNROOT/ global_avail]

[Ferenc Kovacs]

On Sat, Oct 15, 2016 at 4:07 AM, Johannes Schlüter  wrote:

> Hi,
>
> I've restricted access to main/php_version.h. This should restrict wrong
> merges by a bit. Hope this doesn't cause issues. Current RMs should have
> access. This is the current list:
>
> avail|rasmus,johannes,tyrael,ab,jpauli,davey,krakjoe,dsp|php
> -src.git/main/php_version.h
>
> johannes
>
>
> -- Forwarded message --
> From: "Johannes Schlüter" 
> To: php-...@lists.php.net
> Cc:
> Date: Sat, 15 Oct 2016 02:02:15 +
> Subject: [PHP-CVS] svn: /SVNROOT/ global_avail
> johannes Sat, 15 Oct 2016 02:02:15 +
>
> Revision: http://svn.php.net/viewvc?view=revision=340492
>
> Log:
> Limit access to php_vesion.h
>
> This serves as a small mitigation to prevent wrong merges (i.e. merging
> PHP-7.1 into PHP-7.0 instead of the other way round) This won't cover all
> cases, but hopefully reduces the number of issues.
>
> Changed paths:
> U   SVNROOT/global_avail
>
> Modified: SVNROOT/global_avail
> ===
> --- SVNROOT/global_avail2016-10-14 22:23:44 UTC (rev 340491)
> +++ SVNROOT/global_avail2016-10-15 02:02:15 UTC (rev 340492)
> @@ -28,6 +28,14 @@
>  # php-src karma and before lines granting Zend/TSRM karma)
>  unavail||php-src.git/Zend,php-src.git/TSRM
>
> +# Limit access to man/php_version.h as a mitigation for wrong merges
> (this line
> +# MUST come after lines granting hp-src karma and before lines granting
> +# man/php_version.h karma)
> +unavail||php-src.git/main/php_version.h
> +
> +# RMs and a few others have access to main/php_version.h (see unavail
> above)
> +avail|rasmus,johannes,tyrael,ab,jpauli,davey,krakjoe,dsp|ph
> p-src.git/main/php_version.h
> +
>  # PEAR bits in the main php-src module
>  avail|mj,vblavet,dickmann,tal,jmcastagnetto,alexmerz,
> cellog,pajoye,timj,clay,dufuz,bjori,davidc,saltybeagle,
> derick|php-src.git/pear
>
>
>
> --
> PHP CVS Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

hi,

the only case I can think of would be if we were using feature branches,
this change would prevent other people from merging from the dev branches
if the merge touches php_version.h
but I think it is clearly better to have an easy guard against bogus merges
which prevents a feature not even used atm.
and of course we can have a better fix in the future if we ever want to use
feature branches in the php-src repo.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.28 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.28.
Several security related issues were fixed in this release. All
PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.28 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.28

To verify the downloads, you can use the following information:

php-5.6.28.tar.bz2
SHA256 hash:
c55ea3f4aad5a0b65631d01c4468930fd981ad208ffcd242acdf731bcb47548f
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYIoj0AAoJEMK/C8Qzz8izIXAIAJ9oSPnte3aeJFNhKKIaF3Cf
8U4KELeq6AgB/8UzqHKrQxPl74j+JjI5xIgQPoANrzGTB3R5BRGYyc8AuS4tpKZ8
oaagKzoL1Io0vM/r3hzWzxIt8UIhDKVFF+Jd9mc3FNi4zCckM5xhleq2DWsEb76c
x3gUyqZesVEEaTdIOhcqVpV/m4JpKKVzZ8xv3pzEQ3CbteZRCT7GUaf27fejSmOB
2HlZbgMn70CQY0DgbQu58ymXfEqKRBqN6/CXr3e38nwVWiQse4Cgq1jNGLTtGtZc
gFz+Ek/HfT6MPOXKbd11fEflfLA//vbrCcZ4y8PDCBB9U8c8GtB3zW6x7rGsBGA=
=29cZ
-END PGP SIGNATURE-


php-5.6.28.tar.gz
SHA256 hash:
27a47ac15e0868d51181d3909cfe3c63ae9b643a3ab40dc30a75b5b500bce500
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYIoj7AAoJEMK/C8Qzz8izf0kIAMns1OZzYzOV8RQVBsIxLqHP
ggcNy2pi8O4ljtMXVJxeub2fROBtUVUYsjGaM4TryDN7CWiC8TbpYFr9pktO0V65
3SErhTgextpnsXPMpndU53xE0BYEw0G64xSxEFD0FcYAlQoTEqwlhfsbI/OneBKw
oYJuxwIkdNPxtdfBHhRc3kr3u9/bdfrOLL1i+msivH69CC1RK00O1z1ziprvzu+L
E9DaTHm0XV7vSc36aci+Cp42UNnBKfkegrnZpft1mtboTDqVsvkoIhJvd96/ETQD
8CsBfYF40oj42L2aQtAeM7WwMWzd5imc94dq+wnYlinb16xNK6Q6eLWCKnPM5GA=
=8AiN
-END PGP SIGNATURE-


php-5.6.28.tar.xz
SHA256 hash:
07187ba2870f89cef334cd2ad6cb801aeec5eaf283da0293a9a6be75d6786d11
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYIokDAAoJEMK/C8Qzz8iz9z0H/iArRxNBd/aMWaMUyeJHFhYC
8m/1hWF/rCrQYBe2fFjkHkJgNmjfsANHTYtxf0dXEbaVgGI3vZe08Prpxu69112D
Js0Tx989KXOKl3aXmdgX5wq8BlfS3h1Pa9BMuppOkwiq+2p1p4XI5CZtg1bgmGAc
22PeJVOgWQ27H5hAKrXNKYWMtGnuz28hWlZQK/PvQ7FrZkBvV5Xz6VqAO8S6JBkU
y2W25eD8BN9V3WeTIig5F4vxg15mIxUSk8gyQLA7PKWqk47ySZPvi9lLBMQ+3dJu
hMR4HPu6kq/BJMXySkb8J5m61xeRo6v6VPv2x47zNqX27tP+1UFl34u9Cjxn3Wk=
=Rjg6
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

[PHP-DEV] PHP 5.6.28 RC1 is available for testing

[Ferenc Kovacs]

Hello everyone,

PHP 5.6.28 RC1 was just released and can be downloaded from:

http://downloads.php.net/~tyrael/

The Windows binaries are available at http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-5.6.28RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for Nov 10th, if no critical issues will
be discovered in the RC.

In case you think that other projects should also receive this kind
of emails, please let us know privately, and we will add them to the
list of projects to contact.

To verify the downloads, you can use the following information:

php-5.6.28RC1.tar.bz2
SHA256 hash:
c023e37406db91953892b07a9f9880f90a2d617e8c14a24d27cf44d5f23684e3
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYE6X0AAoJEMK/C8Qzz8iz1zMIAL8f1jBcJaYysxfpwh/sD5t4
rmqt0AHdy9BNO+m5d3Os0kAcyqs4Bf7oP6yYec0YIxcRinT01ccKsJF3iAulrOuP
PPMwX3LKBFy8xWzGbyEr6vsbAGQ7oy1/1EV/+GT64YNNnBwDzP9gEXdFZkwCts9J
FPDaRoPcnLiDw7lbWGTB6XnEx3XDaI3aPchToQ+6rSc4EJjZMoukzGk0aVf7FeZa
Yj8WCsRquwBIw5syMMHV06jNOtWyPrVN4VxzIerLZu+uCvJjNuQ3BnN9gy9h2MYH
xmVbVpfSxSVDJLiiYK5Ae+sW8wyP+opJKZzZLz17xlgZ+ncSH2BM/kTENvAidaA=
=YxQ/
-END PGP SIGNATURE-


php-5.6.28RC1.tar.gz
SHA256 hash:
3dc7ee05dd11da3aa7504469815903fa9a17128d8e4f22214e73ae61ea5e89fc
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYE6X7AAoJEMK/C8Qzz8izw4EH/1WCxsDUlC/8gKERIVB1FJeJ
tCgmSiRrGsHz5A7178rPuc+HUsx05ey9G4kM9CqwaPbPJbOeVCxmvan44gl5TUHG
1/RfyLTGlbuAeZsGQ4rWg6LpYSRMr544/RfSmzLM5/s+quuSAIGiJ5i4f58m8rOx
KzAtWnnBOAJ7gIfoKN4itXRwkuhsx6IOeJoFbyY63xBWPiPOuU9BMJwlRzBjHf4o
qjbswWTEFyNW8jNqQWsER/vXrOrbtHlW/IU1soG8g8qH6ircMB6x530cfDN53KHT
eP0alXuqPdH0wooLyK37bHPA14DF5g1Dv1+0essbFkniqJox18WbOhnzwIB4Ozo=
=bWVx
-END PGP SIGNATURE-


php-5.6.28RC1.tar.xz
SHA256 hash:
16e10687cf963c09c7a2e6baf6430325c18a6d40961d1720b4b9bf766413c355
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJYE6YCAAoJEMK/C8Qzz8izlgkIAKDQC+LnRbNMXoUuPilt2SOp
Saaz3D3QNXOjtdm1eB9Ym7Vydb+g4lIAdg+ylxwPoEZc6icNzdMl1lVOydtOn0Pt
O7gOmLNdw8Yd6dyO7V1BmQGM+Uka5dHL4Tk+SaFdC4Sjb9COOq1Iht1516y4pOE8
yslzktcviMskbaTwSCLF+lP9pLWZ9gmeQYnE9u43SzXQWVaE4PBXYV2sPqe8mkQ8
oPJA63Q5lBtdJk4co8N4qLOWm3OoxG5tu6MqIQ8KbS9wCulgpGBspJN3NJdBLT/M
k3W1ab256G9VimYEyEvRZyLlceTu34xcODlX6clwyj4lN7OKALakbjdlmHlD840=
=gaXN
-END PGP SIGNATURE-

Thank you for your support.

Ferenc Kovacs & Julien Pauli

Re: [PHP-DEV] bug classification discussion

[Ferenc Kovacs]

On Fri, Oct 28, 2016 at 11:18 AM, Remi Collet 
wrote:

> Le 24/10/2016 à 07:23, Stanislav Malyshev a écrit :
> > Hi!
> >
> > We have had a bunch of bugs recently which are essentially one and the
> > same issue: PHP 5.6 allows only int-sized strings, but many functions
> > don't check the size of the string they produce. This can lead to int
> > overflows inside php and also can break other libraries that also assume
> > string sizes are ints and this can cause all kinds of weirdness.
> > However, these bugs are very unlikely to manifest in production setting
> > for one simple reason - they require PHP to run with no memory limit,
> > and I haven't seen many setups that run with no memory limit. I'm not
> > going to go into specifics here, since some of the issues are still not
> > fixed, but you can talk to me privately if you need examples or browse
> > changelogs of later 5.6 releases.
> >
> > A twin brother of this is in 7.0 where there are just integer overflows
> > in string size calculations. Usually that requires huge strings as
> > inputs, so also requires running with no memory limit.
> >
> > These bugs are now treated as security issues,
>
> My main concern is not to know if we treat this bugs as security or not.
>
> It is mainly about "classification", and I think "low" risk bugs should
> be fixed using the normal bug process (going in a RC versions) rather
> than a specific process (fixed only at GA time), which should be
> reserved for higher risk bugs.
>
>
> Remi
>
>
>
I agree with Remi, these should be fixed via the normal development process
so we can catch any issues during the RC.
These are basically the same issue, they can be exploited the same way
(which I agree that has a low Exploitability) so we don't really gain much
by keeping them until the final release but we risk a lot from skipping the
general QA process.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Re: lxr.php.net is coming soon.... finally....

[Ferenc Kovacs]

On Tue, Oct 18, 2016 at 9:14 PM, Rowan Collins <rowan.coll...@gmail.com>
wrote:

> On 18/10/2016 11:43, Christoph M. Becker wrote:
>
>> On 18.10.2016 at 09:07, Ferenc Kovacs wrote:
>>
>> the initial setup is done, let me know what did I miss.
>>>
>> Thanks, Ferenc.  It seems that the navigation to symbols in another file
>> is broken.  Consider, for instance,
>> <http://lxr.php.net/xref/PHP-MASTER/ext/gd/gd.c#1269>.  Clicking on
>> php_info_print_table_row gives
>>
>> | Error: File not found!
>> |
>> | The requested resource is not available
>>
>> That also happens for all other identifiers located in other files that
>> I tried.  Don't know what's wrong there.
>>
>>
> Looks like it's generating slightly the wrong link for some reason: it
> goes to http://lxr.php.net/source/s?defs=php_info_print_table_row
> oject=PHP-MASTER but the "/source" segment shouldn't be there. It works
> if you remove it: http://lxr.php.net/s?defs=php_
> info_print_table_row=PHP-MASTER
>
> My guess would be something to do with rewrite rules, and the "source"
> directory exists on disk but isn't supposed to be part of the URL.
>

hi, yeah, on Tomcat the opengrok app is called source, I've the changed the
settings so now that it works both with and without /source in the url.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Re: lxr.php.net is coming soon.... finally....

[Ferenc Kovacs]

2016. okt. 17. 13:49 ezt írta ("Joe Watkins" <pthre...@pthreads.org>):
>
> Morning Ferenc,
>
> I would love lxr back, Adam has a setup in the mean time, but I'm
sure he would not like everyone using it.
>
> More words of encouragement here ...
>
> Cheers
> Joe
>
> On Sat, Oct 15, 2016 at 3:49 PM, Ferenc Kovacs <tyr...@gmail.com> wrote:
>>
>> On Sat, Oct 15, 2016 at 12:36 PM, Christoph M. Becker <cmbecke...@gmx.de>
>> wrote:
>>
>> > On 15.10.2016 at 01:10, Yasuo Ohgaki wrote:
>> >
>> > > Hi all,
>> > >
>> > > LXR is very useful, but the site is down for a long time.
>> > >
>> > > http://lxr.php.net/
>> > >
>> > > Is this going to be fixed or it will be gone forever?
>> >
>> > See <https://bugs.php.net/bug.php?id=72396>.  It appears Dan could need
>> > some help there. :-)
>> >
>> > --
>> > Christoph M. Becker
>> >
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>> hi,
>>
>> I've got access to the new box and promised to set up opengrok but did
not
>> had the time to do it yet.
>>
>> --
>> Ferenc Kovács
>> @Tyr43l - http://tyrael.hu
>
>

hi,
the initial setup is done, let me know what did I miss.

Re: [PHP-DEV] Re: lxr.php.net is coming soon.... finally....

[Ferenc Kovacs]

On Sat, Oct 15, 2016 at 12:36 PM, Christoph M. Becker 
wrote:

> On 15.10.2016 at 01:10, Yasuo Ohgaki wrote:
>
> > Hi all,
> >
> > LXR is very useful, but the site is down for a long time.
> >
> > http://lxr.php.net/
> >
> > Is this going to be fixed or it will be gone forever?
>
> See .  It appears Dan could need
> some help there. :-)
>
> --
> Christoph M. Becker
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
hi,

I've got access to the new box and promised to set up opengrok but did not
had the time to do it yet.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.27 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.27.
Several security related issues were fixed in this release. All
PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.27 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.27

To verify the downloads, you can use the following information:

php-5.6.27.tar.bz2
SHA256 hash:
3b77d3a067b6e9cc7bb282d4d5b0e6eeb0623a828bb0479241e3b030446f2a3c
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJYAM3ZAAoJEMK/C8Qzz8izTjUIAKutWITaam1LbjAeOc9tf8GY
Qhet2DJ+znBuDDKKh7KiaSMbOMxkFJH8RGO5qtXEiP/vfeJ8kqfaxLNS1HjtbOfk
7pB5wkf09LbonZAWHdEKMUrUhiRjyz6vyTcW6irE09oHk3wAcEu5drufTbLyR2eL
1HnkgC2MhQlMjcmM3YWeD52YYl4Lw1Q8PD4r70vLZAAOF38cxRf8Wsza4XfJDr7p
92oDD+x89a5dm7IAZiF6e++uYAMsjq+3TcGhBWHujkBBwmN6l3ehuJpKMNuj7zXF
8EE4rFyi8aHN7l8esJVuv7fS30V3q5X2RkiFV+ch8la6AGBwy6ItJg+JTnJiq/M=
=+V15
-END PGP SIGNATURE-


php-5.6.27.tar.gz
SHA256 hash:
3e6cecec615907587a2b35fa8e7f915f038034dc57530734c2b94d381e664a1a
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJYAM3eAAoJEMK/C8Qzz8izAG8IALllJBL9Ct5PEpplOiINXwhL
jbBRgzplxp73eXGGAVzn0zawNM+Qmbg/Y3FBcpSE/D2JypN1yWx/+q4Tjg0xJ+C6
v9El59PsCNvBhl03SvrjNWp+Ge5JFicY0u3YIVPYtfPQwjCkkFvgYwbsY445smOl
0l+3QF013iZtuIufwY8E89zQFvTsAOUJCWykaGLNsnJR2a8oauXSrHFdB0isn9mQ
Co0FtRePCwLyvh1oWyNjhmtzXdOKrtWcMK8kbwwqUx0T9COMwzMS2aQLS25zM4rQ
7jWEFWKRTM0uprEYwzlRgRQr9GCzINRG2lhLFbJoXRr1sxmerJzY8Bk77fw0OBA=
=Kr1P
-END PGP SIGNATURE-


php-5.6.27.tar.xz
SHA256 hash:
16eb544498339d1d855292826e2e547ab01a31600141094959073e5e10e93ab5
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJYAM3jAAoJEMK/C8Qzz8izICYIAJdEfjhxkLt+xZg5e2DLGtc+
9bmxasDmzrIGcTGH+75VYIUm+2ljCDnAo7ao7fGrSR75k2+23FdOsYtkrRvfQl0/
aaUDIqflDLQn2D7vGKXIOgXK4Tf0gYG6myrHrnCuSg5laiVPQ6tb4/OJ/+pWCO5i
gIQ4txRUsJiVEjLFlGCUszmMzTXgMz16TMYkRonx9PW8l6iYx3+5BYblIzFfCO8s
RvO1A9wphSySuHmGU8jHW0dbjXY+dhbGdLadudqYUhIf6+CO+AhZ1kieFdDwNq1y
889xol9DsWl4ylzw9PHNKijZ4QmfvKcmIf6TA601mTMXFl9nfg4Dd/lQN1fnWiA=
=lrbI
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

Re: [PHP-DEV] Intention to move mcrypt to PECL

[Ferenc Kovacs]

On Thu, Oct 6, 2016 at 12:12 PM, Jakub Zelenka  wrote:

> Hi,
>
> On Tue, Oct 4, 2016 at 5:58 PM, Leigh  wrote:
>
> > Hello list,
> >
> > It is my intention to create a new PECL package for ext/mcrypt, so
> > that it can be removed from master as per the RFC
> > (https://wiki.php.net/rfc/mcrypt-viking-funeral)
> >
> > I do not expect there to be any updates to the extension after it has
> > been migrated, however we voted to move it there.
> >
> > Any objections/comments? If not I'll apply for my PECL account in the
> > next few days.
> >
> >
> I don't think it can be added to PECL as it breaks its licensing rules
> (mcrypt is GPL licensed):
>
>
>- Note: wrappers for GPL (all versions) or LGPLv3 libraries will not be
>accepted. Wrappers for libraries licensed under LGPLv2 are however
> allowed
>while being discouraged.
>
> See https://pecl.php.net/account-request.php
>
> Cheers
>
> Jakub
>

AFAIK mcrypt is gpl, libmcrypt (wrapped by our mcrypt ext) is lgpl so it
would be fine for pecl.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Wiki RFC karma request: duncan3dc

[Ferenc Kovacs]

On Mon, Jan 4, 2016 at 5:42 PM, Craig Duncan  wrote:

> Hi,
>
> I'd like to create an RFC to change the behaviour of counting objects, as
> discussed in the following pull request:
> https://github.com/php/php-src/pull/1672
>
> Please can I be granted rfc karma so I can create this?
>
> My wiki username is duncan3dc
>
> Thanks,
> Craig
>

hi,

sorry for the late response, I've just granted you with rfc karma on the
wiki.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.27 RC1 is available for testing

[Ferenc Kovacs]

Hello everyone,

PHP 5.6.27 RC1 was just released and can be downloaded from:

http://downloads.php.net/~tyrael/

The Windows binaries are available at http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-5.6.27RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for Oct 13th, if no critical issues will
be discovered in the RC.

In case you think that other projects should also receive this kind
of emails, please let us know privately, and we will add them to the
list of projects to contact.

To verify the downloads, you can use the following information:

php-5.6.27RC1.tar.bz2
SHA256 hash:
cfb97698acb6c1b34956fe7dbf5d1117837a06b0d2001b1706c1ebc1c7e5dd20
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJX7bGzAAoJEMK/C8Qzz8izXKQH/0m98+dxl4lD/48L5N41kr9P
GeQ0EJy0jPExxjg+R2DW4PatFMFZEoAiGAdP9s09EXnL8q9sADsEAyQNwTIFL5S0
CHqw5h7EpThIINT7/swbERgWi71oG9RNjRfPb5rId9cQjPmF7JckfyJFcBtxbxTI
lxNs0rAnaIfhZZqnQ7X+09ootCoCGgKy7vvxKL1gChdWU3V/tC72SJU3211bEC51
GVVwwSmk41aI+ZanzGylKOaR8e/N5TjhNRbJ9uac6L3q66PEWg3JVmhMceGJRMP5
pb8+UCrZYS/GZjd8t0LuWJh6dJecGNo2wxnnD2vw34S5MCk0As3Sb6IQb03+tL8=
=8LDJ
-END PGP SIGNATURE-


php-5.6.27RC1.tar.gz
SHA256 hash:
3cc9eea8335a271adc6dda5b9225afac4bd4bf97d7b4db4865f895d2732206c5
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJX7bG6AAoJEMK/C8Qzz8izB8IH/idBe+e1Dxh+YcRK0SNPaz1m
3YCrCU05pOL8AiuWHhQlUlwOGp8IupH+aRg1PkXmqx+stuxAsePPvrOj212KRob8
Uqs0GI4XwSe7OdGEqznQV9hFri94TBbQaU2aKG7Nuz0DrWn+mTVPM7Ux6UWw/Iuu
96nfpTf2FJKEHmJu75E4dXiGLvWom1imaIx2/BhDhNfqA0/Mzp6oSxwK8w8B3VDN
P4m8OhalnVhGkyl+0GIPqLX8ow7ws16qdrrgA6AcCZFP0XllKilldBB5n52NajVk
p3DS3N/91CtNXzLHSwvaA/TpgFflQxk2fIvbPzkzyzIzJR7Ku8YeKlRws/BiZJk=
=Pid6
-END PGP SIGNATURE-


php-5.6.27RC1.tar.xz
SHA256 hash:
3401f7671a70f67894813e7d61eafd468d93f60924cbf4b43a6de2e6a24af00e
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJX7bG/AAoJEMK/C8Qzz8iz4ycH/2aKxz+lFtYRwOxiPY9qLwo+
ZOf5zpNpQNRZxONcYa56u2FYRRnzBWlrySPf8C67ofN3FyczfvFhDBbKxP2Vn637
r0G6EwhJ+/FyIiQ+/xKD8RxrYpJqeoyiYfS+TA/3ow0bqZvk8gwv1y4GsB3NkAJl
jIyDfaJE0chPHhKJP7H+pZ/YU+RxZSxwIUomfYcnw0rMTLVmpx4DpM67IGs3aBZN
7c7lUFT40JHK0UjyY1kGbU8QTZD8dpks3l3bw8u0JVbWy8rrTIcKYm0aTNxvKX8l
ItCqbN/UwdwcvnaNpbmEi7EQkBdo8geCaAOQ9bAE4g69p+JYqI7aoCx6C6KN+Q4=
=IWvA
-END PGP SIGNATURE-

Thank you for your support.

Ferenc Kovacs & Julien Pauli

[PHP-DEV] PHP 5.6.26 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.26.
Several security related issues were fixed in this release. All
PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.26 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.26

To verify the downloads, you can use the following information:

php-5.6.26.tar.bz2
SHA256 hash:
d47aab8083a4284b905777e1b45dd7735adc53be827b29f896684750ac8b6236
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJX2xuUAAoJEMK/C8Qzz8izy+EH/27uoWC4XEQXoOU7ydXFCybJ
Sp9orVJn1eTyPP0sJC81f4k6+fv7V8U8xf4bD8RAasNqQ5Vudkm/SVhEa3PEUSJu
zEnwRsw2xGIVuNjpUWrbtVZ+VnSc1WTp/kUoK5fhgByAn99L9B4iweHEV1akDWWg
MyHwU4yERo7qbZIpNy8YNboz7NO7uVeYJpp6uhLQ5jdvYaiAeuomKUTk1UqbM+Eq
uTvhIQPj8M2qFtZ7gFxdaWvyp+FzfU3hh2gAfZTP7KwfqL4rJmDCxffOy1BPuRgh
erJDXHYX8nPDUkYjYwGcizacL/nXDvDrm1JYaZxZB9NVaA11ZJ2slIEMJVxlGFc=
=NJuH
-END PGP SIGNATURE-


php-5.6.26.tar.gz
SHA256 hash:
f76b6cc23739d9dabf875aee57d91ae73f15e88ddf78803369b8b4728b19b924
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJX2xuaAAoJEMK/C8Qzz8izAogH/iste3QlNdOYjXIcX9OP7XDK
WOKpBJUdE8G9vyKffNhCTgmdYlYZvJgaRn/lJjUhwHIfMBNqi9FHuIYjvkst9RDB
wjPxdIMXWfPE83TS/sImx/XygytHqmOXISh0iYo31wgAMlqgBcxomJssAln4P3Hw
wQyd7uiamiiXjODanWRiPMDT/N/oCdGva9tB0YVu8IUgx/WRJfcUdNgaC9fmQDZT
Datzxl/j37I1SyaXcPa9J1XdYH6AeM8MiJLCyk5zKkYihxbMp1vHgcemyRZU/o2Y
gd65ejkIUIgoJ7xxdy5nCuZTOoI5oV6YgPmVjqY7UWgukUYY3Rr0C1riNp2ZEf0=
=Qsjy
-END PGP SIGNATURE-


php-5.6.26.tar.xz
SHA256 hash:
203a854f0f243cb2810d1c832bc871ff133eccdf1ff69d32846f93bc1bef58a8
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJX2xufAAoJEMK/C8Qzz8izL1IH/iZKMMDFNhROGgGENKkLRFLB
3S+sImkncsD+f/I5PHoCS2idC9Vsc9ty82MSXIl587gp8dVGwgY1Shsi9/5VKgyr
tW/JBeMBMidaNU1TX8hcKe5J4sqpOl3/GkK3XcvpkF2eTA/qdnb83l+mdhqISZek
9qGrRadmXcZsVeVkxANAamJlqP3+Hw+l6u/djSBduUaeu+cAxrWEhFgs/ez14wJX
PazaR6n2/onxAWJh1QNM3sHxbaWYxf5XGw3NObDmvT+DnWiBkm5Gq2IWEN9+M1o+
3zMl1jWm0thBlfSrw/MkbVv4sNL9SGZfvA/QWoYwm+tRTQ6GccN15P9Y0oaLyUk=
=uPJs
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Ferenc Kovacs]

On Mon, Sep 12, 2016 at 1:51 PM, Nikita Popov <nikita@gmail.com> wrote:

> On Mon, Sep 12, 2016 at 1:42 PM, Ferenc Kovacs <tyr...@gmail.com> wrote:
>
>> On Mon, Sep 12, 2016 at 10:21 AM, Derick Rethans <der...@php.net> wrote:
>>
>> > On Mon, 12 Sep 2016, Pierre Joye wrote:
>> >
>> > > This RFC is about stop bundling it with the php releases and propose
>> > > composer/pickle instead. Everything else has nothing to do with this
>> > > RFC (aka web frontend, what happens or not on pear.php.net, its
>> > > packages, etc.).
>> > >
>> > > To all: please re focus to the topic.
>> >
>> > It's curious to see though that the off-topic comments get replies, but
>> > few real concerns do from the RFC author - such as not removing
>> > something before we have a confirmed alternative. I'd like to trial
>> > pickle first for a few releases and only then see whether to remove the
>> > PEAR/PECL installer.
>>
>>
>> yeah, unfortunately when the thread gets flooded with off-topic mails it
>> is
>> easy to miss some replies in the noise.
>> I do agree that it would be better and easier to only vote for bundling
>> pickle instead of also voting for unbundling PEAR at the same time.
>>
>
> Is it (technically) possible to unbundle PEAR while leaving PECL?
>
> Nikita
>

not really, we pull the pear installer directly from
https://pear.php.net/install-pear-nozlib.phar there is no option to only
install the pecl stuff, so it would either require a major rewrite on
pear-core and a new release, or maybe we could try something like doing a
standard install then proceed and delete out files (like pearcmd.php) as
part of make install but that would be still sucky.
and we still have most of PEAR core around and still no pecl package
install support on windows.
with bundling pickle we could remove the PEAR dependency and pickle would
also work on windows.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Ferenc Kovacs]

On Mon, Sep 12, 2016 at 10:21 AM, Derick Rethans  wrote:

> On Mon, 12 Sep 2016, Pierre Joye wrote:
>
> > This RFC is about stop bundling it with the php releases and propose
> > composer/pickle instead. Everything else has nothing to do with this
> > RFC (aka web frontend, what happens or not on pear.php.net, its
> > packages, etc.).
> >
> > To all: please re focus to the topic.
>
> It's curious to see though that the off-topic comments get replies, but
> few real concerns do from the RFC author - such as not removing
> something before we have a confirmed alternative. I'd like to trial
> pickle first for a few releases and only then see whether to remove the
> PEAR/PECL installer.


yeah, unfortunately when the thread gets flooded with off-topic mails it is
easy to miss some replies in the noise.
I do agree that it would be better and easier to only vote for bundling
pickle instead of also voting for unbundling PEAR at the same time.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Ferenc Kovacs]

On Mon, Sep 12, 2016 at 10:24 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> >> PEAR/PECL as a package manager has historically had little utility to
> the
> >> average user apart from installing those PECL extensions which aren't
> >> packaged by a particular user's distribution repository. Certainly
> hasn't
> >> had any real viability in years. Trying to replace something that's
> >> inherently non-viable
> >
> > I beg to differ - this time with stats:
> >
> > https://pecl.php.net/package-stats.php
> > https://pecl.php.net/package-stats.php?pid=981==7
> > https://pecl.php.net/package-stats.php?pid=214==25
> >
> > Literally millions of downloads, and recently too.
> >
> > The PECL installer is in *wide* use.
>
> Is the stats for downloads by every mean or just by downloads via the
> installer specifically? I.e., if I just download it by clicking the link
> in web GUI, it is counted, or only when I use installer?
>
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
it is counted by the get/fetch script which serves the file, and afaik
that's also what pear-core is calling.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Ferenc Kovacs]

On Mon, Sep 12, 2016 at 9:32 AM, Tony Marston 
wrote:

> Sent: Sunday, September 11, 2016 11:44 AM
> >To: Tony Marston
> >Cc: Stanislav Malyshev ; internals@lists.php.net
> >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
> composer/pickle
> >
> >On Sun, Sep 11, 2016 at 4:47 AM, Tony Marston 
> wrote:
> >
> >Sent: Saturday, September 10, 2016 7:47 PM
> >>To: Tony Marston ; internals@lists.php.net
> >>Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
> composer/pickle
> >
> >
> >Then I suggest that those who are so anxious to see of death of PEAR/PECL
> should be forced to provide a viable alternative first. Otherwise they
> would be just like those stupid politicians who try to force commuters out
> of their private cars and into public transport without realising that the
> existing public transport system is NOT a viable replacement and is
> incapable of taking on the extra load.
> >
> >I just want to say that PEAR as a source repository, has been dead for
> quite some time. It's filled with outdated code that has hardly seen any
> maintenance in years, and nobody really contributes to it anyway.
> >
> >PEAR/PECL as a package manager has historically had little utility to the
> average user apart from installing those PECL extensions which aren't
> packaged by a particular user's distribution repository. Certainly hasn't
> had any real viability in years. Trying to replace something that's
> inherently non-viable with a viable-alternative seems like a pretty moot
> point.
>
> Just because you have found no use for it does not mean that others feel
> the same. How about those large numbers of websites that have to use PEAR
> Mailer instead of the built-in mail() function? I personally use SVNManager
> to manage my SVN repositories, and this is dependent on one of the PEAR
> modules, so there is a very recent use. How many other PEAR modules have
> been installed and are still is use? Do you have the download statistics
> for all the PEAR modules? That would be much more accurate that all this
> guesswork and supposition.
>
> --
> Tony Marston
>
>
we have download statistics for pear/pecl:
http://pecl.php.net/package-stats.php
http://pear.php.net/package-stats.php
but it would be better to filter the stats to a more recent time interval
like last year or something, not sure if that is possible with the current
web interface, but you can see the recent download stats on the package
page, eg:
http://pecl.php.net/package-stats.php?cid=33=876
http://pear.php.net/package-stats.php?pid=14=19

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Modern practices ...

[Ferenc Kovacs]

On Sat, Sep 10, 2016 at 10:32 AM, Lester Caine  wrote:

> On 09/09/16 14:28, Lester Caine wrote:
> > I'd forgotten the official windows packages no longer had PEAR anyway.
> > Does make the discussion on that somewhat academic? We have been
> > installing Linux servers as replacements to the windows boxes so the
> > need to actually load newer windows builds as been rather rare, and I
> > was using a stacked version when I did ... which is another alternative
> > to distributions on windows.
>
> Doing some digging I've found the conversations on this back in 2011. At
> that time the statement was made that 'php project does not provide
> binary builds' and 'if the user can't install a compiler they should not
> be using php'. I'll not name the source ... it was a thread on this list
> in 2011.
>

interesting, could you direct me to the thread at least?
I couldn't find anything with those exact quotes and I'm subscibed to the
list longer than 2011.
the only platform we provide binaries is windows,but we provide official
windows binaries since like forever (and least as I can go back in history,
php 3.0.11 at least), so that quote is either incorrect, or comes from
somebody uninformed, or have some specific context you are not quoting with
it.


>
> The problem that we were discussing at the time was availability not
> only of PHP on windows but also Apache, and the fact that neither
> project provides official builds on windows.


as I mentioned before (and mentioned in every release announcement) php
does indeed provide official windows binaries, you are correct that apache
http project does not.


> While there were 'free'
> paths to do your own builds on windows and I had documented my own
> process at that time. These were NOT acceptable by government agencies
> to provide audited installations. Windows applications come pre-compiled
> and while I think that the more modern build paths can be download for
> free they are not free for commercial use?


I'm not sure what do you mean by this, but this probably depends on your
own policies and the distributions you decide to grab your builds from.


> An 'official' compiled build
> is a requirement for windows. Although that does not necessarily need to
> be provided by PHP. Apachelounge is an approved source amongst my
> customers.
>

yeah, Apache Lounge is one of the available option to grab apache http
binaries for windows, and also endorsed by the apache httpd team:
https://httpd.apache.org/docs/current/platform/windows.html


>
> I think I am right in saying Pierre originally needed pickle so that
> PEAR could be dropped in the windows?


Not sure why did you get that idea, as mentioned before the windows team
already unbundled PEAR from the core since 5.3 or so (which imo makes sense
as pecl wasn't really an option for building and installing pecl extensions
on windows).


> So the only element left is
> bundling PEAR with the source distribution. I've not had to worry about
> PHP7 on windows as yet as the few sites were are allowed to use it are
> linux servers, but it will come a point when we need to audit a PHP7
> windows installation, along with a web server. And it looks as if while
> 5 years ago nginx was ahead of apache, the commercialization of the
> former is taking it off the play list :( Just when I've got it working
> nicely as a background to testing multiple copies of PHP on the same
> code. This is about making PHP easily available across the board and
> while windows may now be confined to the desktop machine, it is still
> more popular than linux on commercial and government systems?
>

sorry, can't really decipher this part, maybe it's just me.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Re: VCS Account Request: adambaratz

[Ferenc Kovacs]

On Fri, Sep 9, 2016 at 5:14 PM, Ferenc Kovacs <tyr...@gmail.com> wrote:

>
>
> On Fri, Sep 9, 2016 at 5:12 PM, PHP Group <gr...@php.net> wrote:
>
>> VCS Account Approved: adambaratz approved by tyrael \o/
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> hi,
>
> I've approved your account, I will grant you appropriate karma when I get
> home.
>
>
I've granted you with ext/pdo_dblib karma, it takes a couple of hours to
propagate, let me know if you need further help.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Re: VCS Account Request: adambaratz

[Ferenc Kovacs]

On Fri, Sep 9, 2016 at 5:12 PM, PHP Group  wrote:

> VCS Account Approved: adambaratz approved by tyrael \o/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
hi,

I've approved your account, I will grant you appropriate karma when I get
home.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Modern practices ...

[Ferenc Kovacs]

On Fri, Sep 9, 2016 at 1:45 PM, Lester Caine <les...@lsces.co.uk> wrote:

> On 09/09/16 12:35, Ferenc Kovacs wrote:
> > but please, this is really offtopic on this list.
>
> See my other reply ...
> and composer global mode as provided out of the box is NOT an
> alternative to installing the sort of production and development -
> command line - tools that PEAR currently manages happily. I AM trying to
> learn composer, and I can see now how it can be used, but simply passing
> the buck to getcomposer is not the way to use it for a default PHP
> installation.


composer is proven to be capable managing those use-cases but it isn't our
duty to write out the detailed migration guides for every usecase between
PEAR and composer.
our duty as the php-src group is that we provide a way which allows the
management of the pecl extensions (pickle install and maybe providing an
alternative for pecl package) and tell people how can they install PEAR if
they still need it (https://pear.php.net/manual/en/installation.php)
for the record most distributors already decouple PEAR from the base php
install (php-pear is a separate optional package on debian/ubuntu, the
windows binaries doesn't have PEAR at all, you have to manually install it
there, etc.) and from the php-src point of view we only use it to provide a
way of installing pecl extensions, which will be solved with pickle so
while educating people to migrate their workflows from PEAR to composer is
a noble goal, but it isn't our responsibilities and we don't have to solve
that to be able to replace our php c extension management tool shipped with
the core.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Modern practices ...

[Ferenc Kovacs]

On Fri, Sep 9, 2016 at 1:00 PM, Lester Caine  wrote:

> On 09/09/16 11:30, Niklas Keller wrote:
> >> Back to PEAR ... what happens if I simply install a copy of composer
> >> > centrally and rename it 'PEAR'.
> >
> > Why rename it to PEAR? It's a different tool. Just call it Composer as
> it's
> > named.
>
> My point was just that as has already been established. composer can do
> the same thing as PEAR. All that matters is that everybody is working
> from the same global installation. The composer.json/composer.lock that
> controls a particular installed application is secure to that
> application not an individuals account.
>

usually what's best it that you learn the new tool and apply it to your use
case instead of trying to make it work the same way as your previous tool
blindly.


>
> >> > composer.phar simply gets installed
> >> > centrally and any new tech has access without having to install their
> >> > own copy.
> >
> > That's entirely fine as said. New tech should still install their own
> > version of the repository and install the dependencies there.
>
> Then you have never had a full security audit of your systems! A new
> user should NEVER install their own version of anything relating to the
> running system. THAT is a potential hole in the security of the system.
> The new user should simply be given access to the locked down code
> already installed.
>
>
not sure I understand who is a user in that example.
are you arguing that your developers shouldn't ever be allowed to change
code? (allowing them to install dependencies is basically the same as
allowing them to change code)
if that's true why would you have developers in the first place?
changing code is fine, as long as you can audit those changes before it
goes to production and if you can make sure that the audited code will be
the same that goes to production.
the current industry best practice is to separate the build and deployment
steps, so you can inspect and verify your application before those two
steps.
with composer that usually means that you won't ever execute composer
install on your production machines, but installing your dependencies is
part of your build process which results in an artifact (which can be
anything from a directory of files, or a debian package, a docker container
or an amazon AMI) which then can be inspected, installed in isolation, put
through automated testing or manual QA then you can release it without any
chance that it will be different from what you ispected.
I'm not saying that everybody needs such complex release workflow, but you
sounded as secure system would be only possible with a system wide PEAR
install but not with composer or application specific dependency
installation in general.
but please, this is really offtopic on this list.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Modern practices ...

[Ferenc Kovacs]

On Fri, Sep 9, 2016 at 10:39 AM, Lester Caine  wrote:

> Having slept on the discussion about people today expecting users each
> to have their own environment, I came to the something of an impasse.
> How many Linux installations run a package manager that allows
> individual users to install their own versions of
> Apache/PHP/Database/Git/Hg and so on.


usually it isn't the distributions jobs to do that thanks to the spread of
virtualization and containerization but even distros moved to a direction
where you can install multiple versions in parallel or run multiple
instances of a service with different config.
some distros like gentoo supported this since forever, others only changed
recently (for example Ubuntu changed their package naming scheme with the
latest lts which is a big step to the parallel versions), and there were
other projects which was created for the specific purpose of installing and
running multiple versions in parallel (https://github.com/cweiske/phpfarm
and https://github.com/phpenv/phpenv for example)
and if we move away from php, and check out other similar languages like
python or ruby, they also moved to the direction of allowing the
application to specify it's own environment:

with ruby they have https://github.com/rbenv/rbenv
https://github.com/rvm/rvm to let apps specify their ruby environment, and
there is also https://github.com/chef/omnibus for creating a self contained
application which brings it's own embeddid environment so it has zero
external dependency.

with python you https://github.com/pypa/virtualenv and have
https://github.com/yyuu/pyenv and there is a tool (
https://github.com/pantsbuild/pex) which can be used to create a single
executable file which contains and executes your python application
together which it's dependencies.


> The whole point being that the
> machine has a consistent framework that everybody knows. Even adding
> extensions to PHP they will be added to the single version, which is why
> I expect extensions like 'composer' to be installed centrally so when I
> run it I know it's the same version that every other tech is using.
>

this is the old school way of doing this, and was mostly superseded because
each application has it's own set of requirement (for dependencies and for
configuration options) and when you want to manage multiple applications in
a single environment it will be either hard or impossible.
of course the system wide installation philosophy is still fine as long as
you only manage a single application in that system.


>
> Now I have no problem with each user pulling their own clone of the code
> via Git or Hg and creating their own 'play area' to check out bugs and
> there is nothing to stop them running multiple copies of the PHP code
> against the central web services. They are testing in parallel with the
> live code in an identical environment. But obviously it would be safer
> to have a second mirror machine installed with the same version of
> distribution on which to test, and in an ideal world one would update
> the development machine, run all the test and ensure there are no
> problems before allowing the production machine to roll over. I did say
> ideal ;)


indeed, and you want to have a reproducible environment for other reasons
too.


> Most sites will skip whole major versions of updates simply
> becuase their production system IS working ...
>

usually it is easier to migrate in multiple smaller steps, but of course
there are people who will do the one big upgrade.


>
> Back to PEAR ... what happens if I simply install a copy of composer
> centrally and rename it 'PEAR'. composer.phar simply gets installed
> centrally and any new tech has access without having to install their
> own copy.


as I and others mentioned before composer does user/system wide
installations: https://getcomposer.org/doc/03-cli.md#global but not sure
what do you mean renaming it to PEAR, they have different command line
format, etc. you can't just rename it and expect it to work.



> As with Git/Hg users can have their own play areas USING
> composer, but to be honest from a safety point of view one knows that
> the version of composer being run has not been infected with some
> injection mechanism. We keep going on about validating the PHP code
> against malicious attack, but the whole framework is open to that?
>

not sure I follow what are you trying to say here, so from the past your
devs were not allowed to add new PEAR dependencies, but someone else did
that for them? and now you are afraid that if you introduce composer they
will install random packages they will introduce something malicious?
First, if adding PEAR packages was a burden in the past, I'm fairly sure
that you have a couple of PEAR packages just manually committed to you
repository as part of your project.
with composer you don't push your dependencies to your repository, but with
the composer.lock you can guarantee that installing 

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Ferenc Kovacs]

2016. szept. 9. 10:44 ezt írta ("Tony Marston" ):
>
> Sent: Thursday, September 08, 2016 9:35 AM
> >To: Tony Marston
> >Cc: PHP Internals
> >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
composer/pickle
> >
> >
> >On Thu, Sep 8, 2016 at 9:49 AM, Tony Marston 
wrote:
> >
> >"Michael Morris"  wrote in message
news:CAEUnE0dfjJ02g2Rhkp9WvnkSXpoLzjK=tmivdbsucccgxw2...@mail.gmail.com...
> >
> >
> >
> >On Wed, Sep 7, 2016 at 3:52 AM, Tony Marston 
> >wrote:
> >
> >Typical. You create a useful tool, get your users hooked, then walk away
> >and leave them dangling.
> >
> >No one owes you anything. You aren't entitled to get free updates to a
free
> >tool. If the author wants to move onto other projects, that's their
> >prerogative. Stop with the bombastic and abusive tone towards everyone,
> >particularly the developers, on this list.
> >
> >Please point out to me any words I have used which a reasonable person
would class as "abusive".
> >
> >"Incorrect. There is a web interface which I use EXCLUSIVELY to maintain
the contents of my PEAR library. Any proposed replacement which does not
have a web interface I'm afraid is totally unacceptable. Command line
interfaces went out of fashion when the Windows OS was first released, and
anyone who still insists on using one has not joined the rest of the world
in the 21st century."
>
> I repeat, show me any personal insults in what I wrote. All I see are
“fair comments”.
>
> >you inject your subjective opinion/anecdotal evidence as an objective
fact and trying to kill the discussion instead of contributing to it.
> >as you mentioned there is a pear package which provides a web interface
for managing pear packages, but that isn't part of the pear core and hence
not bundled by the php project atm, so I don't think that it is a valid
argument for requiring to bundle a gui interface for composer. if people
need a web interface there will be a web interface (maybe there is one
already: https://github.com/composer-ui/composer-ui ) which they can
install via composer.
> >
> >"Just because SOME people still like using a command line interface does
not mean that they can force everyone else to use it. If any piece of 21st
century does not come with a web/GUI interface it just shows that the
author is still living in the past and is incapable of serving the needs of
today's users."
>
> >first you are arguing in bad faith (eg. that anybody/everybody here is
trying to sabotage those who would prefer a gui over a command line), then
you start namecalling those who would prefer command line over gui (which
is btw. plain wrong in the age of configuration management and immutable
deployment where being able to have automated and reproducible deployments
is a key)
>
> I repeat, show me any personal insults in what I wrote. All I see are
“fair comments”.
>
> --
> Tony Marston
>

Your original request was "Please point out to me any words I have used
which a reasonable person would class as "abusive".",
now you are moving the goalpost to personal insults (which for the record
still happened when calling people living in the past and such for using
cli tools), which again shows that you are arguing in bad faith.
Please take a moment and check out our mailing list rules at
http://git.php.net/?p=php-src.git;a=blob;f=README.MAILINGLIST_RULES;hb=HEAD
and please try to follow those otherwise you will be removed from this list.

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Ferenc Kovacs]

On Thu, Sep 8, 2016 at 9:49 AM, Tony Marston 
wrote:

> "Michael Morris"  wrote in message news:CAEUnE0dfjJ02g2Rhkp9WvnkS
> XpoLzjK=tmivdbsucccgxw2...@mail.gmail.com...
>
>
>> On Wed, Sep 7, 2016 at 3:52 AM, Tony Marston 
>> wrote:
>>
>>>
>>>
>>> Typical. You create a useful tool, get your users hooked, then walk away
>>> and leave them dangling.
>>>
>>>
>>> No one owes you anything. You aren't entitled to get free updates to a
>> free
>> tool. If the author wants to move onto other projects, that's their
>> prerogative. Stop with the bombastic and abusive tone towards everyone,
>> particularly the developers, on this list.
>>
>
> Please point out to me any words I have used which a reasonable person
> would class as "abusive".
>

"Incorrect. There is a web interface which I use EXCLUSIVELY to maintain
the contents of my PEAR library. Any proposed replacement which does not
have a web interface I'm afraid is totally unacceptable. Command line
interfaces went out of fashion when the Windows OS was first released, and
anyone who still insists on using one has not joined the rest of the world
in the 21st century."

you inject your subjective opinion/anecdotal evidence as an objective fact
and trying to kill the discussion instead of contributing to it.
as you mentioned there is a pear package which provides a web interface for
managing pear packages, but that isn't part of the pear core and hence not
bundled by the php project atm, so I don't think that it is a valid
argument for requiring to bundle a gui interface for composer. if people
need a web interface there will be a web interface (maybe there is one
already: https://github.com/composer-ui/composer-ui ) which they can
install via composer.

"Just because SOME people still like using a command line interface does
not mean that they can force everyone else to use it. If any piece of 21st
century does not come with a web/GUI interface it just shows that the
author is still living in the past and is incapable of serving the needs of
today's users."

first you are arguing in bad faith (eg. that anybody/everybody here is
trying to sabotage those who would prefer a gui over a command line), then
you start namecalling those who would prefer command line over gui (which
is btw. plain wrong in the age of configuration management and immutable
deployment where being able to have automated and reproducible deployments
is a key)

"Typical. You create a useful tool, get your users hooked, then walk away
and leave them dangling."

bad faith and passive aggressive comment.

 "Perhaps users could be prevented from making such basic mistakes if they
had a 21st century web interface instead of the archaic command line."

I've replied to this already, but yet another passive aggressive remark
which adds little to nothing to the discussion.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Ferenc Kovacs]

On Thu, Sep 8, 2016 at 9:43 AM, Tony Marston <tonymars...@hotmail.com>
wrote:

> "Ferenc Kovacs"  wrote in message news:CAH-PCH568TPsztkWT553QVQy
> 7jsp1tcqt5w+ot1pocdt-pb...@mail.gmail.com...
>
>>
>> On Wed, Sep 7, 2016 at 9:49 AM, Tony Marston <tonymars...@hotmail.com>
>> wrote:
>>
>> "Ferenc Kovacs"  wrote in message news:CAH-PCH5qHdYen33Q_s7kTKM_
>>> 8qk71v8ky6kt4fzurfawfx0...@mail.gmail.com...
>>>
>>>
>>>>
>>>>
>>>>> Composer doesn't do that.
>>>>>
>>>>>>
>>>>>>
>>>>>> Then how come I've seen several complaints in various forums about
>>>>> composer updating libraries in the background and screwing things up.
>>>>>
>>>>>
>>>> That proves nothing except that your knowledge is very limited.
>>>>
>>>>>
>>>>>
>>>>
>>> indeed it does.
>>>>
>>>>
>>> I can only report what I have read in various newsgroups and forums, and
>>> they have said that composer has screwed up their installations. If it is
>>> capable of doing that then it is a serious issue that needs addressing.
>>>
>>
>>
>> you can, but you shouldn't spread FUD but do your own research.
>> composer will only do something when you execute it, without providing any
>> actual problem, there is no way those could be refuted (FUD), and brings
>> nothing to the discussion.
>> what you have probably seen is people not using the tool properly
>> from my experience people usually screw 2 things up:
>>
>>   1. executing "composer update" without any arguments which will update
>>   every package listed in your composer.json file to the latest version
>>   allowed by the version constraints
>>   2. not putting the composer.lock under version control and then being
>>   surprised that the other developer who makes a "composer install" from
>>   composer.json can have different(eg. more recent) versions installed
>>
>
> Perhaps users could be prevented from making such basic mistakes if they
> had a 21st century web interface instead of the archaic command line.


perhaps, or perhaps they would misclick, but now you are again trying to
divert the discussion from actual problems to the land of FUD.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Re: The death of `#ifndef FAST_ZPP`?

[Ferenc Kovacs]

On Tue, Sep 6, 2016 at 12:33 AM, Andrea Faulds  wrote:

> Hi again,
>
> I finally wrote a patch to get rid of it:
>
> https://github.com/php/php-src/pull/2118
>
> Perhaps this will go somewhere. :)
>
>
> --
> Andrea Faulds
> https://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
+1 from me on the idea.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Ferenc Kovacs]

On Wed, Sep 7, 2016 at 9:49 AM, Tony Marston <tonymars...@hotmail.com>
wrote:

> "Ferenc Kovacs"  wrote in message news:CAH-PCH5qHdYen33Q_s7kTKM_
> 8qk71v8ky6kt4fzurfawfx0...@mail.gmail.com...
>
>>
>>
>>>
>>> Composer doesn't do that.
>>>>
>>>>
>>> Then how come I've seen several complaints in various forums about
>>> composer updating libraries in the background and screwing things up.
>>>
>>
>> That proves nothing except that your knowledge is very limited.
>>>
>>
>
>> indeed it does.
>>
>
> I can only report what I have read in various newsgroups and forums, and
> they have said that composer has screwed up their installations. If it is
> capable of doing that then it is a serious issue that needs addressing.


you can, but you shouldn't spread FUD but do your own research.
composer will only do something when you execute it, without providing any
actual problem, there is no way those could be refuted (FUD), and brings
nothing to the discussion.
what you have probably seen is people not using the tool properly
from my experience people usually screw 2 things up:

   1. executing "composer update" without any arguments which will update
   every package listed in your composer.json file to the latest version
   allowed by the version constraints
   2. not putting the composer.lock under version control and then being
   surprised that the other developer who makes a "composer install" from
   composer.json can have different(eg. more recent) versions installed


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Ferenc Kovacs]

On Tue, Sep 6, 2016 at 12:40 PM, Rowan Collins 
wrote:

> On 06/09/2016 11:18, Derick Rethans wrote:
>
>> One of PHPs biggest strengths is the availability of an extension for
>> nearly everything. There are *1000s* out there. Some made by single
>> people, some by small groups of people, or some by large companies. You
>> can't expect *all* of these extensions to be available through
>> distribution's packages.
>>
>
> By the same reasoning, most of them won't be available on pecl.php.net
> either. I'm curious, do people often run their own PECL-compatible
> "channel" servers?


in the past it was a pita so nobody really done it, but then Fabien
contributed Pirum (http://pirum.sensiolabs.org/) after that for a while it
was "hip" to run your own pear channel(from server/channel side pear and
pecl is the same).
nowdays most active projects switched from custom pear channels to
composer/packagist


>
>
> They'd still need to run the equivalent to "pecl" to install these
>> manually build extensions. Or at least the "pecl download" variant.
>>
>
> Not really, the ones I've used come as a tarball, use "phpize" and
> standard build tools, and have a "make install" to put the .so file in the
> right place. Then you just have to add "extension=foo.so" in the
> appropriate ini location (which you have to do after pecl install anyway).
>
> I agree that a stable tool for installing from pecl.php.net should always
> be included, though.


agree, and on windows we could dramatically improve the situation, afair
Anatol recently added the capability for peclweb to link/list the windows
binaries for the pecl releases, and pickle uses the dll-s from
windows.php.net to be able to install the pecl extensions without requiring
the build toolchain to be present:
https://github.com/FriendsOfPHP/pickle/blob/71fd8a97ac6c3f67fbb7f032533ddaa31cb6b662/src/Package/Util/Windows/DependencyLib.php


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Ferenc Kovacs]

>
>
>> Composer doesn't do that.
>>
>
> Then how come I've seen several complaints in various forums about
> composer updating libraries in the background and screwing things up.




> That proves nothing except that your knowledge is very limited.


indeed it does.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Ferenc Kovacs]

2016. szept. 5. 17:32 ezt írta ("Michael Morris" ):
>
> Please be cautious - composer isn't a complete replacement for PEAR
because
> it doesn't behave the same way. For the most part this is a good thing,
but
> please consider the following.
>
> On not one but two occasions I was tasked after being hired with upgrading
> PHP versions from 4.x to 5.3.  In both cases the programmers on staff who
> had inherited the balls of mud in question swore up and down it couldn't
be
> done - on both occasions it was because they weren't copying the PEAR
> libraries over to the new PHP install.
>
> PEAR is a global installer, and unfortunately I imagine there are a lot of
> legacy sites that have been inherited by inexperienced coders who don''t
> know what it is (cause it is used so rarely these days) that have pear
libs
> in use. If they need to build a new version of PHP they are at a complete
> loss unless they know what they are doing because, more often than not,
the
> requirement of pear libraries in PHP apps that use them go undocumented.
>
> Composer is superior for several reasons, but one of them is that it
> doesn't share this flaw. The requirements of a composer project are listed
> explicitly in the composer.json file - often down to the version # of the
> code in question.
>
> While abandoning PEAR seems sensible, abandoning its plugins, not so much.
> To say nothing of PECL extensions which are, if I recall correctly,
written
> in C++ and extend the PHP runtime directly.
>
> Also, as Tony Marston pointed out, there are CPanel systems that allow the
> pear libraries to be managed from a web gui.  Given time I'm sure the
folks
> at cpanel will build new interfaces for new systems if it's possible.
> Composer however doesn't really allow for this since the dependencies
> belong to the PHP application, not the server. Does it make sense for any
> new system to allow for server wide installing?  Composer does have global
> requiring, but it's usually for support tools meant for use at the command
> line like PHP Unit.
>
> Despite the misgivings above, I do support the aims of this RFC and hope
> they are considered going forward.
>
> On Fri, Sep 2, 2016 at 3:32 PM, Davey Shafik  wrote:
>
> > Hi internals,
> >
> > I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and
remove
> > in 8.0), as well as add composer/pickle (optional in 7.2, default in
7.3+)
> > in their place.
> >
> > https://wiki.php.net/rfc/deprecate-pear-include-composer
> >
> > I highly recommend reading the twitter poll and accompanying thread at
> > https://twitter.com/dshafik/status/756337267547832320
> >
> > I believe that pickle solves the issues with regards to pecl, and have
run
> > the idea passed Jordi and Pierre. Both are fine with this RFC. :)
> >
> > I understand that adding in composer/pickle is just setting us up for
> > having a future "Deprecate composer/pickle & Replace with foo/bar" RFC,
so
> > I've proposed the voting reflect that some people will just want to
> > deprecate/remove pear/pecl and not replace them at all.
> >
> > I'm also proposing voting choices around the optional/default
introduction
> > of composer/pickle.
> >
> > - Davey
> >

For the record pear support local install and composer also provides global
installmethods but you are right that they use the opposite by default.

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Ferenc Kovacs]

2016. szept. 2. 21:58 ezt írta ("James Gilliland" ):
>
> On Fri, Sep 2, 2016 at 2:33 PM Davey Shafik  wrote:
>
> > Hi internals,
> >
> > I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and
remove
> > in 8.0), as well as add composer/pickle (optional in 7.2, default in
7.3+)
> > in their place.
> >
> > https://wiki.php.net/rfc/deprecate-pear-include-composer
> >
> > I highly recommend reading the twitter poll and accompanying thread at
> > https://twitter.com/dshafik/status/756337267547832320
> >
> > I believe that pickle solves the issues with regards to pecl, and have
run
> > the idea passed Jordi and Pierre. Both are fine with this RFC. :)
> >
> > I understand that adding in composer/pickle is just setting us up for
> > having a future "Deprecate composer/pickle & Replace with foo/bar" RFC,
so
> > I've proposed the voting reflect that some people will just want to
> > deprecate/remove pear/pecl and not replace them at all.
> >
> > I'm also proposing voting choices around the optional/default
introduction
> > of composer/pickle.
> >
> > - Davey
> >
> Will composer/pickle address the unsolved PHP compatibility issue that
> makes pecl a pain following the PHP 7 release?

You are probably talking about https://bugs.php.net/bug.php?id=71224.

My understanding is that when fetching the packages from pecl.php.net
pickle would still have the same problem (
https://github.com/FriendsOfPHP/pickle/issues/133) but if pecl authors
start adding composer.json to their repos you can describe the php version
dependency for the given extension on a per tag/version basis.

I still think that it would be worth implementing
https://bugs.php.net/bug.php?id=71224

[PHP-DEV] PHP 5.6.26 RC1 is available for testing

[Ferenc Kovacs]

Hello everyone,

PHP 5.6.26 RC1 was just released and can be downloaded from:

http://downloads.php.net/~tyrael/

The Windows binaries are available at http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-5.6.26RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for Sep 15th, if no critical issues will
be discovered in the RC.

In case you think that other projects should also receive this kind
of emails, please let us know privately, and we will add them to the
list of projects to contact.

To verify the downloads, you can use the following information:

php-5.6.26RC1.tar.bz2
SHA256 hash:
de04edc5debd84d025b3efda90b2a2305e263147b8231164bf470705692b7ae1
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXya+jAAoJEMK/C8Qzz8izxiUH/j8vzZCJMx4yBxgTrN2a2hiv
elmEVGX27mQMgEQxD/jpXspiHiQvvDOSBpnup43amJOfJlgE0Jlwi6mxbrkk1uoT
J3888VhtkQuosoOyGgG3MRXcAN80xdbjc5NhzWBff02cEJFxTSR+c9ggiT4018a8
8N+nObZdWkm2LcC8MKEzDKToVf4DmpWWDooanxgfPeGPTnGsboyZS1aQ+Qi/dMxo
CbV8iEIB6DsHCnoO2YW7vnvQY88rjs3a8ix+zwC307mNVQTLdGAwcNexlYjSh/Ov
EujSBIII8Blu6lvvJvDOtJyJqD6MXmE7io7n/pdQrU/ymGSZpTQ9nrnEnFFp7k0=
=3fAW
-END PGP SIGNATURE-


php-5.6.26RC1.tar.gz
SHA256 hash:
315cc09980ce69a00fda86e0efead68219f820c889163fbfdfbfc7203caeda80
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXya+pAAoJEMK/C8Qzz8iztNEIANR6HrEKtUwvM8YqC/AKivFH
CQsWDvFlpoq0PAbTvsf3hFcevfwE/EG/9X9VIi1HIuvwl6by2ZF6lefuHJDfPAy2
GPyojZToXEAGVLIbIJTVl1sdU+fdYix8zzgtQeH0hHv3u54hfk2iS75J0Y5PQ/Gu
hBjbXYK3QobDL9Lousl2PLP7fHMC3+XjEL8YlmUuscQgL4E4nT0ugG3RCnH49JTC
3lL99UU0RFnxgLCHGSvXyzdDm32VLxebE2fvIHZ/5Sw6TH0+JEtL45z8lauZhhUD
8YUn0VmECgdJ1pdfXriiS0pqPH8aELf5Uliiksji/csO0V1q6AAERsTgp1/AMkE=
=Z46U
-END PGP SIGNATURE-


php-5.6.26RC1.tar.xz
SHA256 hash:
239ba56c86765f8fcebd0bf8ba8f798194fc37e1b6c55d26403861509ae7b309
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXya+vAAoJEMK/C8Qzz8iz70wH/jdwG5TSUV+nYbjfceGOgkVL
8d7AwN7pZk4fdYwvzYeAA+u2mZlHeGlLGyVC355vmia0vATH3tEV/yzykowM8TAJ
HMvkB69SfQ/iLsHJg3UD6AHExJxaTs43ZfMvXO3LBsBZfRoRERqGmRtJt9A10kN8
Np4ZL7lhVuPlEN0LXov3kUeLCalnoq6uVNaxGKKJrk3nYSUMkqp1Cs+/gZfrSFrX
aM2f6GpKs2YTx3srVAr5v3PRdcM9pFrmlwIXKZjpsOkGl/rOJMH9Qd9olLJ4ohEI
91pmXBlLdYcdv9HwBI6xf4UHxHLqvPsZLUPfBlDSQH2nrg4dRad1tHKAZoFeZLY=
=0Y/0
-END PGP SIGNATURE-

Thank you for your support.

Ferenc Kovacs & Julien Pauli

Re: [PHP-DEV] BC break: ReflectionMethod::invoke() expects parameter1 to be object, string given

[Ferenc Kovacs]

On Mon, Aug 22, 2016 at 6:30 PM, Christoph M. Becker 
wrote:

> On 22.08.2016 at 18:00, Julien Pauli wrote:
>
> > I agree this is a BC break and should not stay as-is in source code.
>
> I wonder why we have more than 100 lines of "Backward incompatible
> changes" in the PHP 7.1.0beta3 changelog[1], if BC breaks shouldn't be
> introduced in a minor release.
>

That's a bit loaded question, and leads to a broken windows situation, but
from my understanding some people read
https://wiki.php.net/rfc/releaseprocess differently: consider some BC
breaks simply bug fixes, or think that we shouldn't stick to absolutes but
consider BC breaks on a case-by-case basis.
personally I think tha


>
> > It makes some testsuites fail, that did not fail before ; thus it breaks
> things.
>
> An estimated 10% (at least) of my *bugfixes* in GD broke at least one
> PHPT, because the test was broken in the first place.
>

test failures can be false positive or depending explicitly undefined
behaviors, but they can be a good indicator when looking for BC breaks.
as we can see from the previous mails in this thread there are behavior
changes where the previous behavior was different from what was documented
so a bit of a grey area.

personally I think that we are in general too lenient with allowing BC
breaks in 7.1 (even though that I somehow expected this and was arguing for
a longer release cycle for 7.0 or at least having a clear roadmap for the
next major version) and we should be more strict about it otherwise we will
lose the trust we gained from the userland in the last couple of years with
our release process and versioning.



-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] BC break: ReflectionMethod::invoke() expects parameter 1 to be object, string given

[Ferenc Kovacs]

On Mon, Aug 22, 2016 at 4:16 PM, Pierre Joye  wrote:

> On Aug 22, 2016 9:01 PM, "Levi Morrison"  wrote:
> >
> > On Mon, Aug 22, 2016 at 5:17 AM, Nicolas Grekas <
> > nicolas.grekas+...@gmail.com> wrote:
> >
> > > Hello,
> > >
> > > now that the BC break on ReflectionType has been reverted, another one
> > > remains in ReflectionMethod::invoke():
> > >
> > > the method doesn't accept a string as first argument anymore, see e.g.:
> > >
> > > https://3v4l.org/pImmv
> > >
> > > As you can see, this worked since 5.0 and even in HHVM.
> > >
> > > It would be great to fix this BC break please.
> > >
> > > Regards,
> > > Nicolas
> > >
> >
> > According to the [documentation][1] it requires an object. If the
> > documentation has not been altered recently to make it this way then I'm
> > inclined to keep the backward compatibility break. Your example uses a
> > static method - you should be passing null and not the name of the class
> > (this is also in the documentation).
> >
> >   [1]: http://php.net/manual/en/reflectionmethod.invoke.php
>
> I have to disagree here.
>
> Many codes out there uses string. What is the appealing reason to break
> these codes in 7.1?
>
> I think it should restore the precious behavior and if the docs need a
> fix,  let fix it, not the other way.
>
> Cheers
> Pierre
>

Hi,

If it was explicitly documented to be expecting an object, then altering
the code to match the documented behavior can be considered a bugfix, but I
agree that if it is moderately/widely used we should consider keeping the
old behavior instead of removing it in a minor version.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.25 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.25.
Several security related issues were fixed in this release. All
PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.25 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.25

To verify the downloads, you can use the following information:

php-5.6.25.tar.bz2
SHA256 hash:
58ce6032aced7f3e42ced492bd9820e5b3f2a3cd3ef71429aa92fd7b3eb18dde
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXtj+8AAoJEMK/C8Qzz8izrdcH+wbq+5XDyrq/I3LQYrA6JK90
bNvIx+ysI3VMdabhjH38GZEqpUSnLJl+3c4okMXcvYZJD6Ew1k4MICkX522nMsjc
AkTD1irgcQqB5Qo3jYwJA8jJLf6SmnINZm984w/dFCIDAvtrUJlEJKjcrWSAFblM
VrK06+84wb64GVhXZSIXHiKe4jTX6HgPVAQYj0us9n6vazndrdHN+BR7SgxMfKnF
GXu7FzM95ta8qNNaSxS3MI74wa5VWZfC21q/8TlZbYE1fLGnwOdFkOFKy4OTd7BR
wZIPIi7SXZKenA2HwDsHNIUbNLPTADBdeAO0rMg/o9dMjFf3hGVL3E1LI6ViwV8=
=5XPU
-END PGP SIGNATURE-

php-5.6.25.tar.gz
SHA256 hash:
733f1c811d51c2d4031a0c058dc94d09d03858d781ca2eb2cce78853bc76db58
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXtj/JAAoJEMK/C8Qzz8izZHwH/3VXuzpznPi7R+9ZwYYuufJb
jHuMiBNrkKuYK1XSu2zjsBAcCQ9HYVzbC71sZI4wMBpwFhR3g6omMZt70Po0YsFV
b1AWeO5rbeP8LTcY1KMUM4YdwMdadq21hn6quKzBjEBonuTPOdnH0kFxyOszVBT8
b/h/mMtw3TOQxxgemtY+GBIZ2Fs2M+BO6nePvMDXXtLCQh7Ch3NQcBNRf29v2ARN
TNpz6plfIb3VFzHyA0arpoDHZ7PlfpxKVU+FN8VtRfVe4rmtLkeOPMkOS2EkJ7PG
IdLMg5D8cm+ESVR5JSuoq1S9Q6boITODCHUIiOjQhDiRT2n6wDtF+CFh02fgRsg=
=GMkK
-END PGP SIGNATURE-

php-5.6.25.tar.xz
SHA256 hash:
7535cd6e20040ccec4594cc386c6f15c3f2c88f24163294a31068cf7dfe7f644
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXtj/PAAoJEMK/C8Qzz8izoskH/RKpdvxYAY4QUt3M6w/x6oKa
gcY5V1fgZa+zqqPTqb7BR/INBdVd+CMzIejxG/xLKiD6bi5BNkz5MV+3SwdRSoEj
ZNU3CWNa0WU2DoLzt0F6PzwPKQgF2TrpC3JuRsOUsRCHhdN+ebU5ECnXTQlHPmIP
cZegFG63G+E7duJabluDRM/LPWyJSD9gz4zaKTEmjE3KtKu6IJTLHXPb4iu+kHbN
HubTw3j6pEf1c9xIimT7dX8brWYPZQUojxsapC1XxxD5CqEnsWCSt23fYrLYblYF
BbhaXq0xuZ1/tTV7yo5g5a0BTOHRoG60sxa43KyuMDyTrnbudwCOTfokYn9FyIg=
=JExa
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

Re: [PHP-DEV] Wiki karma for writing RFC

[Ferenc Kovacs]

On Thu, Aug 11, 2016 at 6:05 PM, Michał Brzuchalski 
wrote:

> Hello,
>
> I would like to submit an RFC for adding object type hint. My wiki account
> name is brzuchal.
>
> Thanks,
> --
> Michał Brzuchalski
>

Hi,

I've just granted you with rfc karma for the wiki!

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] RFC Karma

[Ferenc Kovacs]

On Tue, Aug 9, 2016 at 1:07 PM, Silvio Marijić 
wrote:

> Hi Internals,
>
> I would like to create RFC for immutability in PHP which has gone trough
> couple of discussions, so I need RFC Karma for that. Michal Brzuchalski and
> I will be authors and we will implement it.
>
> Best regards,
> Silvio Marijic
>
> --
> Silvio Marijić
> Software Engineer
> 2e Systems
>

Hi,

I've just granted you with rfc karma for the wiki!

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.25 RC1 is available for testing

[Ferenc Kovacs]

Hello everyone,

PHP 5.6.25 RC1 was just released and can be downloaded from:

http://downloads.php.net/~tyrael/

The Windows binaries are available at http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-5.6.25RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for Aug 18th, if no critical issues will
be discovered in the RC.

In case you think that other projects should also receive this kind
of emails, please let us know privately, and we will add them to the
list of projects to contact.

To verify the downloads, you can use the following information:

php-5.6.25RC1.tar.bz2
SHA256 hash:
0b972a862e8354f40b16238d15af88665032686177ab1b29ac35c4d8635c8056
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXo9g6AAoJEMK/C8Qzz8izfOEH/1/4Eb1ol+efWze4cO5GDNMh
HWJBPJDAd612YkP0PEMRkhp4XKpcURCDXis7J+sXIfKLcPGmF3isG2To/1fyy/Y1
fdSwt2JjYa34p6RHnxG+PwFjuR+nxN6TxmFUygFv1St+UsXzQ/SC2RWO8VUXNP8t
FRo/xuHiZDnNerO49trLWzBHtQsiTFotSy8Sas8/9EkOPtSehNp87HVe2xzj7Qi0
nUBl7txenpBpYFKp6ar82rZ36oB2oMB3SmBYXbvDdb6ZCXR/UEcvYmPNRt4yPvML
npyVkK6vJk/f3J04ddGq7B8xwqq+C5vHD7bk85vlCn8p3LLDvg1etCA2l+8exh8=
=EM5R
-END PGP SIGNATURE-


php-5.6.25RC1.tar.gz
SHA256 hash:
47a7322029a61d5d7bd3226f4308c26f60152c3aa5f6957dd9079266d141af44
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXo9hFAAoJEMK/C8Qzz8izmtMIAMSjzONGIiZl7HOzMRBZY9M+
o3KwxdFg/2vsGJvCaly0pSwQRX5DK4Wpu8yXfQVHp9OpKjpb6Biy6D7O2MfzKlbQ
S1NvHBVGuQ0uhzixQ6P4SM+gnQrPdFh30aRX+TedSjqjfddzyCr5kLy1K6kMHd/e
nw+I/wt0WW/QuMCQ92qUTPWKjL/ZtMuE+wZw0uNzl8XeMkLK8UH8RH459IUPVQA1
k0qj0Ko6vV5k18tTL7duMRO/vkpIS8ycm6WT4MFA0H/yrkYpp2BG2tcXlN0y5Je9
q2giRdDsMW+zA3TbtOapp9H5EijCzkMTVHxemR1yLnKaJDekolDZ5IRvuphSp6w=
=3kTX
-END PGP SIGNATURE-


php-5.6.25RC1.tar.xz
SHA256 hash:
da6ac5c97eedbb8b271c8668aaff2ccd2b1beb04dfa551b5980c44a92a40bbd3
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXo9hKAAoJEMK/C8Qzz8izmMcIAJ6Xt9SuPIzmu5mwyHbFf5gn
GLqbwFzrvOHiUIaeV27N80SlFHkawWk13HT+Ic88RIbxOkIttZ8qzX2XQ3drxTBq
bwnwy3uZA/S9VdoMsbNJufFLYMvLqzW8wDi8By9GE69PgMt5wBVzaDX4Td6I45lL
65ZGix16fHSUA5tB53IwRlapserixdlrApLAVT0pO72Elg4xYSIRG/QOllQrZ2vj
xEzhJBO2OC2qk4z8cVNG2J+mPqGJJO5bimqb031PzKWP/7Par4qo7SQPe1rK2eEW
qazbG2BEYlWoTeIXYUAnxsVWwZkfrcrZ4gDw+4dxb1+FWv6/W35BkVqkjBG7tTk=
=esNu
-END PGP SIGNATURE-

Thank you for your support.

Ferenc Kovacs & Julien Pauli

Re: [PHP-DEV] RFC Karma Request

[Ferenc Kovacs]

On Tue, Jul 26, 2016 at 8:41 PM,  wrote:

> Hello,
>
> I would like to submit an RFC for adding a str_begins and str_ends
> function, in relation to https://bugs.php.net/bug.php?id=67035 and
> https://bugs.php.net/bug.php?id=50434. I've added those functions on my
> local PHP copy. I would like to make an RFC and a PR for adding it to the
> core PHP copy.
>
> Thanks,
>
> Will
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
hi,

I've just granted you rfc karma on the wiki.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Request for rfc karma

[Ferenc Kovacs]

On Mon, Jul 25, 2016 at 9:57 PM, David Walker  wrote:

> Hi All,
>
> I'm desiring to propose my second RFC (thanks bishop for the intro)
> regarding PR2031  . Seems there
> has been a couple PR's attempting to raise a notice when accessing
> non-array-like containers; and I'd like to propose something to attempt to
> resolve the open bugs/PR's.
>
> wiki user: bp1222
>
> Thanks
> --
> Dave
>

hi,

I've just granted you with rfc karma on the wiki.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Request for wiki karma

[Ferenc Kovacs]

On Wed, Jul 13, 2016 at 11:53 AM, Jesse Schalken 
wrote:

> Hi internals,
>
> I'd like wiki karma to write an RFC for the feature of setting
> properties/calling methods within an expression with the result of the
> object itself, eg
>
>
> $this->fooMethod(new FooParams() {
> setBlah(BLAH_CONST + 1),
> prop1 = $foo,
> prop3 = $builder->create() {
> prop1 = true,
> prop2 = $this->getBaz(),
> },
> });
>
>
> Wiki Username: jesse.schalken
>
> Also, if anyone has an idea for the name of the feature, please let me
> know. The best I can think of is "object-expressions".
>
> Thanks
>

hi,

I've just granted you rfc karma on the wiki, sorry for the delay.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.24 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.24.
Several security related issues were fixed in this release. All
PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.24 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.24

To verify the downloads, you can use the following information:

php-5.6.24.tar.bz2
SHA256 hash:
bf23617ec3ed0a125ec8bde2b7bca9d3804b2ff4df8de192890c84dc9fac38c6
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXkCAnAAoJEMK/C8Qzz8izPDoIAO0i4rnokMspfh1/rifkO91d
fBAThS+PvPFsQphVMxskY65bQnrVmkDTzghvWNsSMbeoFXLE66Sw0xU11dn5z+t6
If2pgtywyJvjH5uNQE8xDfUHgpeNVLqtnSKMsxOmg4iOK6CZq7TsFAxIzmuH1tEX
Fc6JMnLrYCBMc1LGpVEqWZJTw1tXZqicsLW1WF1CHs7QzYCMvRswFM9vTdwjSWOy
ATNcFWa0avwyTji+nloNLOPQh1VRGynzM8jLSkOysLjHXwbwxrqaBVqyRdhj6Foh
T0CcZU2GhX4hJtJnJLoipRcRT/Gl3TFYUa4zyNlu9bd5bdIheci3WPh/ioF4HrI=
=Bs66
-END PGP SIGNATURE-

php-5.6.24.tar.gz
SHA256 hash:
5f8b2e4e00360fee6eb1b89447266ae45993265955bd1ea9866270d75cdb6ec1
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXkCAyAAoJEMK/C8Qzz8izwvMH/iIjkHLbDou0FgtLnnUFS2+p
ik/4uyyQ7bf9zVbcBy4LgRd/9qWBANt7aHVL4G1ITm3Y6Lfs2yop4aTdQkGm7bDE
ArulBQX4un9xOSq77S7FSfz1Cg7V18swbWZzs2ECY6bziMzCcwR5cFp3ikEUYwva
o7zFRoe2UmlGdddtwCxgC0vhejxKF7AoBTXXYC3pSrT7znnfE5oa083yGBPQ7fUR
Hg+lh1k+jsnW/msvG6kFvlGF6BW/3xDEH0+wFj7Qin4VzDfdEqGl4y84yF34CUks
5dNk7JCbrJf30H+2xBzuWYBq8UZtVyyCPENaMnFFYYO+rGuU8YWsRUI9kv8062E=
=O96R
-END PGP SIGNATURE-

php-5.6.24.tar.xz
SHA256 hash:
ed7c38c6dac539ade62e08118258f4dac0c49beca04d8603bee4e0ea6ca8250b
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXkCA5AAoJEMK/C8Qzz8izPlkH/jV4dd6tlE+hEHL90YbPlXMT
7BLgC3Bcc64AqPEIBejCzNN6HJjoqitDrPAHZWKSu8k4RP6Itigv+ZPlOyJ2Gjek
jCuO63ErW/kgz8rKeH6wHYX4Z2EVZqTmSE7eNGRKV+DtzW8KXAaOqiqXznEHqsc7
Hj8IAgYDIE4oYoCchHBGsO1TB9oCOIDAZ3ogFED6SQLnnrzqpXhiWmaWaeCOB8Ay
oSFW4+FYEmfaDuE8a7BgNFySPBqCFQ0JYuvNilRVUwrKkE9UKPiJHLrA7GWwH9W1
Dvs1KRyY/NA1v1tXPn7CpxMSs/rCq7VbA1XjsHeul+AI3gpZRuQI04GrSXy54GU=
=Cu4K
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

[PHP-DEV] force push in php-src

[Ferenc Kovacs]

hi,

we had a wrong merge in the php-src, merging master into 5.6. I've just
force pushed the last good version before the bogus merge. You can find the
bogus state at https://github.com/tyrael/php-src/tree/broken-5.6-20140206
if you happen to have some commits which you still want to have in PHP-5.6.

In case you *pulled* between that wrong merge and the fix git will
reject doing a fast forward merge in that case please put your local 5.6
(and master accordingly) branch aside and reset to upstream, then cherry
pick local changes.

This might be an approach:

   $ git checkout PHP-5.6# Go to your local 5.6 branch
   $ git pull# Results in error "can't fast-forward"
   $ git branch backup-5.6   # create a backup
   $ git reset --hard origin/PHP-5.6
 # Overwrite local 5.6 with upstream
   $ gitk PHP-5.6 backup-5.6 # Investigate changes, cherry pick etc.
   $ git branch -D backup-5.6# Remove backup (warning: no
 # confirmation before deletion, be sure
 # there's none of your work left!)

Re: [PHP-DEV] Request for wiki karma

[Ferenc Kovacs]

On Sat, Jul 9, 2016 at 9:37 PM, Charles R. Portwood II <
charlesportwoo...@erianna.com> wrote:

> Hello Internals,
>
> I'd like to improve the password_* functions by adding support for
> Argon2[1], the winner of the Password Hasing Competition[2].
>
> I've previously implemented an extension[3] to handle this, however I
> believe this would be better to have Argon2 implemented directly password_*
> functions. I would handle implementation of this enhancement, and would
> like to gather your feedback before formally proposing an RFC.
>
> My wiki username is: charlesportwoodii
>
> Thank you!
> *Charles R. Portwood II*
>
> [1] 
> [2] 
> [3] 
>

hi,

I've granted you with rfc karma on the wiki

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.24 RC1 is available for testing

[Ferenc Kovacs]

Hello everyone,

PHP 5.6.24 RC1 was just released and can be downloaded from:

http://downloads.php.net/~tyrael/

The Windows binaries are available at http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-5.6.24RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for Jul 21st, if no critical issues will
be discovered in the RC.

In case you think that other projects should also receive this kind
of emails, please let us know privately, and we will add them to the
list of projects to contact.

To verify the downloads, you can use the following information:

php-5.6.24RC1.tar.bz2
SHA256 hash:
716c31a93095eb6ebd294af72bcc8e435515a625ddeadd6d1251cba3096f7d66
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXftXPAAoJEMK/C8Qzz8izQbAIANGZr0b0LBhREidd3Jyb86LR
snQ86+ctD2xkFWuQcItHanrSmfKJYFS5kadny99qIVm0+In65Ta/8KauEceBwrM1
qAfxsTwVKone/BcVlWTcpwtuy1r6FOrgyRJvKmGsNwsfcd7OunhrMBapRwkcWasE
fxR+X0Un88alerxC8JbM6oSF9SQU0et03u4sA/jvkVBany3vdeOpRkwfL1r2u7lV
PuUjxC7TgRrzlekA+DUHO7rCnHEdswy46eZWxQkjqiqiHOngzpbCC1OkiSt4PVmg
Ojap7lfLnoqzYBCdFp8DiNMko4vZ34plqE3t1sDlMM2POptTlp/4cBSlMSuB+Uk=
=snAC
-END PGP SIGNATURE-

php-5.6.24RC1.tar.gz
SHA256 hash:
94f75a6c5d2c90190d463297964ef629bc83d524fcee41a866b42b75b18de028
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXftXWAAoJEMK/C8Qzz8izoMYH/0+5lx/hHte+HdsQ5i1jJ5f8
LVJJV69UjKdESBATKU2J190CqtL/KiNXaukW0OXO9V2jKeRcjLMYw6CdH0wnXtZI
5zOPLY53UGWNPEHI5O9VrUPfRAwrv0+p2ymZisK81mb44pIoTrj68l5Q/9sLzDxX
YwK6DXzHY/7GYBYmuyr3eXHkoY6Xxz1A4/5c0WIx6TRIRfM5bCQGsQaf2FuQhf63
K8LnATolIXCH4jFAm2asJmqRiLwl+cQJqd5l/qSlZ5BEZZj0OpgHBLvyksGZT04T
GUEpntxBUEh2clznt4w7fJhktk9Jw46vDHLi819pku1/tYTzM2eujwAjMrrO+UY=
=zIq4
-END PGP SIGNATURE-

php-5.6.24RC1.tar.xz
SHA256 hash:
2c3c530f5e197017be80a785818d4e5990fba4ae45e4edda0908da7359b0b2e7
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXftXcAAoJEMK/C8Qzz8iz5K8IALnpD5kbgv6A8koyRnzcLrB9
2OMnGG4b2ozgmg6oc7wfDmQiOPCZHvsF8b/CS1IvEn2wLVkJ3JwzA2LqAfufcxF4
G48LVSPuQtbkjCyCTTos5CI8v7QfGcwEkUhvayl8DIXSztMJMxRZGuR9gp6vqznt
+g2TPBtjgb9KEsjMViMwFjDh/jABnYP5ils2nFDQjtvj7WlqI5nJzlNDYTtkY+Ud
upOvCHQ9s9wUicdDVDex07mXmdvTtb3KoEI5KctWgeuJ8ryiq0ejLFUxIPA+yISi
EQzUXfCVbspcam/jpoLhq1mARtfyg3BKfJSXaOiou7yUSUa6Bs1eJziw+bvvomw=
=jNGE
-END PGP SIGNATURE-

Thank you for your support.

Ferenc Kovacs & Julien Pauli

Re: [PHP-DEV] Request for Karma

[Ferenc Kovacs]

On Tue, Jul 5, 2016 at 4:51 PM, André Rømcke  wrote:

> Hello PHP Team,
>
> Even if to late for 7.1, it’s summer time and I’d like to contribute to
> moving forward on updating a RFC for Property Accessors Syntax
> to bring that up to level of 7.x.
>
> I’m not a C programmer so I’m interested in finding someone to co-write
> this with. As for background I’m leading the teams involved in
> developing and maintaining eZ Publish and now eZ Platform. Open
> source CMS solutions that has PHP roots since it’s start around 2000.
> I have been voting member of FIG and member of this mailing lists
> for several years, and hope to find a viable solution for everyone.
>
> For now please grant my wiki user edit access, and if any core member
> would have interest in mentoring me on this, that would be great.
>
> Username: andrerom
>
> Best regards,
> André R.
>
>
>
hi,

I've just granted you with rfc karma for the wiki!

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] New escaped output operator

[Ferenc Kovacs]

On Sun, Jun 19, 2016 at 6:53 PM, Михаил Востриков <
michael.vostri...@gmail.com> wrote:

> Please give me RFC karma. My wiki account is "michael-vostrikov". I plan to
> create an RFC for this feature.
>
>
hi,

I've just granted you with rfc karma on the wiki.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Request for Karma

[Ferenc Kovacs]

On Sat, Jun 11, 2016 at 5:19 PM, Fleshgrinder  wrote:

> I would like to request Karma for the Wiki.
>
> I would like to write RFCs for the features that I develop and help
> others with their RFCs.
>
> My Wiki username is "fleshgrinder".
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>
hi,

I've granted you with rfc karma

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Ferenc Kovacs]

On Mon, Jun 13, 2016 at 4:32 PM, Joe Watkins  wrote:

> Afternoon internals,
>
> > Is there a roadmap somewhere that describes this, or any background
> discussion of doing this within the 7.x series, rather than planning for
> 8.0?
>
> We have no such sensible thing as a plan :)
>
> The reason for the existence of PHP 7 (ng) is efficiency of the kind I
> described, this is surely well understood by everyone.
>
> What may not be well understood is that the job is nothing like complete.
> Vigilant observers will have noticed that Dmitry does indeed have a JIT for
> NG, which is very useful research, but it sucks so hard that we can't
> deploy it.
>
> The reason for this is that, in part, generated code doesn't look so much
> different to code executed by the VM, though details differ considerably;
> It needs to do at least the same job, it may need to do more (because of
> guarding and other boring things).
>
> Without knowing anything about generating instructions anyone can tell
> that a complicated Zend, with all kinds of edge cases and inconsistencies
> (specifically regarding ZE) is going to necessitate the generation of
> complicated code, to accommodate those edge cases and inconsistencies.
>
> A lot of effort is being put in to finding and resolving inconsistencies
> in the engine such as this, a lot of effort has been expended and will be
> expended on 7 in the pursuit of efficiency. A lot of this is of no
> consequence to BC.
>
> You can count the number of people putting in the majority of this effort
> on your fingers ... erecting a road block in front of them in the name of
> unobtainable BC is harmful to the apparent goals of the project at this
> time.
>
> The kinds of changes that must be delayed until 8.0 are surely going to be
> proposed, and we will surely delay them by consensus.
>
> > This is my main concern, also
>
> I will update the RFC, if Dmitry doesn't, when voting is closed.
>
> I will ensure the change is properly documented in the manual also.
>
> > Ideally, this could lead to a revised policy
>
> I think our policy has always been to consider each proposal on a
> case-by-case basis. That's all I have done, and all I am suggesting others
> do.
>
> I know it's very strange to hear someone talking about "goals" ...
>
> We can waste a bunch of time trying to define them, voting on them, and so
> on ... or, we can look at what is going on, and what has gone on, and come
> to sensible conclusions.
>
> Cheers
> Joe
>
>
>
On the other hand lack of release process and constant BC breaks also
hindered the adoption of past PHP versions.
With 7.0 we were in a good spot as we were able to package the BC breaks
with major performance improvements which makes it attractive for people to
upgrade(and still, with a successful 7.0 release we voted to delay the eol
date for 5.6).
While I don't want to impede progress we have to be careful about BC
breaks, and especially when from the outside it can be seen as some people
are above the rules/processes while others get gated by it.
>From the user POV I really liked what we were doing in the past: mark stuff
first with E_DEPRECATED and then remove the feature later on.
I think that our main problem is that we don't have a roadmap for major
versions and historically our major release cycle was pretty slow (4.0.0:
2000, 5.0.0: 2004, 5.3 was basically a major version in 2009 and 7.0.0:
2015 dec), so now that a major just shipped people will try to squeeze in
BC breaks regardless of our release process (and yes, it doesn't not help
that the releaseprocess rfc was lacking clear definitions on some terms).
As I mentioned before I don't wanna impede progress so not trying to block
this specific rfc seeing how well the votes went, but I think it would be
useful for the future governance if we could:
1, update/expand our releaseprocess rfc so that it reflects the
actual/desired process and can spare us from the bureaucracy and word
twisting to suite one's current position.
2, figure out how can we do BC breaks in a more timely manner (either via
changing the releaseprocess, reclassifying what BC break means or having
more frequent major versions).

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Ferenc Kovacs]

Hi,

my interpretation is that no rfc with BC breaks should target a minor
version.
Our interpretation(based on past decisions and mailing list discussion) of
BC break is changing any userland API except where we excplicitly stated
that the previous behavior is undefined (and we also allow extensions to be
moved to pecl, which from user POV can be a BC break but we allow that
explicitly).
I see a trend with php 7.1 that people try to add everything which we
couldn't finish in 7.0 as it would be a complementary php 7.0 release, not
a standard minor release which should abide our release process(
https://wiki.php.net/rfc/releaseprocess ).
Let me summon Anatol as he was the 7.0 release manager and Joe and Davey as
they are the RMs for 7.1, let's see what do they think about this.

On Sun, Jun 12, 2016 at 6:42 PM, Rowan Collins 
wrote:

> tl;dr:
>
> - We have an RFC [too_few_args] about to pass that seems to break our
> published Release Process.
> - Is the vote invalid, or do we need to change the Process?
> - The opinions of those who voted "Yes" are particularly requested.
>
>
> Hi All,
>
> The RFC to Replace "Missing argument" warning with "Too few arguments"
> exception [too_few_args] looks certain to pass (it currently stands at 36:8
> in favour), and contains the following:
>
> Backward Incompatible Changes: "The BC break in intended."
>>
> > Proposed PHP Version(s): "PHP 7.1"
>
> This appears to be in direct contradiction with the Release Process RFC
> [releaseprocess] adopted in 2010, which states:
>
>  "x.y.z to x.y+1.z ... Backward compatibility must be kept"
>>
>
> There are two interpretations of this:
>
> 1) The policy in [releaseprocess] is binding, and the vote on
> [too_few_args] is invalid. Either the results should be ignored, or
> silently taken as acceptance of the feature in 8.0, and implementation
> postponed. However, there is no provision in the RFC for enforcement, and
> the RMs are explicitly denied such a role:
>
> "The roles of the release managers are about being a  facilitator ... But
>> they are not: Decide which features, extension or
>>
> SAPI get in a release or not"
>
> 2) There is some reason that [releaseprocess] can be ignored in this case.
> However, there is no mechanism I can see in [releaseprocess], nor any
> justification in [too_few_args] or on its associated mailing list threads.
>
>
> It is often argued that "No BC" is too broad, and thus unenforceable. It
> is probably impossible to give a water-tight definition of what is
> acceptable, but we can state some general principles.
>
> The Introduction to [releaseprocess] implies the following aim:
>
> - To ensure a smooth and predictable upgrade process between minor
> releases.
>
> From this, I would consider the general spirit of the BC rule to be:
>
> - Any reasonably written PHP application which runs successfully under PHP
> x.y.z should run successfully under PHP x.y+1.z without significant
> modification.
>
> For instance, a program which runs fine under 5.3 may need invasive
> changes to remove call-time pass-by-reference before it runs on 5.4;
> preventing this seems to be the intent of the rule.
>
>
> Here is where things begin to get subjective, but the following seem
> reasonable to me, and seem to match most decisions made up until now:
>
> - Notices, Warnings, etc, may change severity, but must not become Errors
> or Exceptions.
> - An Error may be removed, or downgraded to a Warning, etc, if there is
> good reason to do so, e.g. new behaviour gracefully handles a previously
> unhandled case. (Many of the cases below boil down to this.)
> - The defined behaviour of operators must not change.
> - New operators, or application of operators to new situations, may be
> added, where such application would previously have been a error.
> - New keywords, functions, and classes may be reserved in the global
> namespace, because PHP "owns" this namespace. However, this must be done
> with care, and following the naming guide.
> - New arguments or type cases may be added to built-in functions.
> - Old arguments must not be removed from built-in functions.
> - Functions must not be removed, except for the special case of moving a
> "bundled" extension to PECL, such that loading the PECL module restores
> full compatibility.
> - Accidental and undocumented behaviour ("bugs") may be changed if some
> effort is made to demonstrate that it is not widely relied on.
> - The above rules may be broken only with careful justification, e.g. to
> remove a major security issue.
>
> Note that [releaseprocess] already states that justification must be
> provided for BC breaks, even where it allows them:
>
> It is critical to understand the consequences of breaking  BC, APIs or
>> ABIs (only internals related). It should not be done for
>>
> the sake of doing it.
> > RFCs explaining the reasoning behind a breakage and the consequences
> along with test cases and patch(es) should help.
>
>
> If the 

[PHP-DEV] PHP 5.6.23 RC1 is available for testing

[Ferenc Kovacs]

Hello everyone,

PHP 5.6.23 RC1 was just released and can be downloaded from:

http://downloads.php.net/~tyrael/

The Windows binaries are available at http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-5.6.23RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for Jun 23th, if no critical issues will
be discovered in the RC.

In case you think that other projects should also receive this kind
of emails, please let us know privately, and we will add them to the
list of projects to contact.

To verify the downloads, you can use the following information:

php-5.6.23RC1.tar.bz2
SHA256 hash:
e20ba10c07b4c3a9006e08e7e824e3c061416846e143a20f5cdb9b3a5e94e647
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXWnRAAAoJEMK/C8Qzz8izSvEH/2YBaqofMKBDZN+fZ97/72eH
mHg2qc5cEta/r1TcIXvEbEEjIzTjP8CXenvW6RTIsvapc8jZMN/085H50gqi8Wfl
vTOJc5wKaDT2lgfRrXBYtQUSXSem+7pFl5HAN4AyRVKOdCObdFhfYQg6RSX294Ih
iAopePLB+EBr8HPFUIJ2VexkWzEsguUfK77dGUqEL1DE0QzY8sK76kRqpNBW+sJl
q+9o8Q/3ZJLdEnV32GnRwqsVwjT1VqePpUhFVAKD9yXN202RF2tJYfhQnEArr8Bt
sEoM33YZ3N6X4cHV6F4LIKar4bLVsm5PktxQNC71NnFeb4lCEGhGHvcGioM0A4A=
=Nysc
-END PGP SIGNATURE-

php-5.6.23RC1.tar.gz
SHA256 hash:
b39f3cd2231bc206dec684f491647affaa0d04f844b3ec1d6a90c906e523
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXWnRIAAoJEMK/C8Qzz8izTsEH/jd+xma5FbSI3a46ZDp7dP5x
CQGOGXDQojpWtw60N/OUH3K4Sa0wEuxWTOSCa3oJPbGfE8UB7oSKDq+X6I+txGmL
1/32rNe//IrRbos/z7jTAD5qmWYItfKrxZHknHwZW4NX/V/J4YCIg2uCahl4imYe
WoynocBuQ+gYWDUnnsq+t65sw+NA9p7uXfATifCNHiqdqAZOcQPuvpfcq6ErKu+V
foiD/AdrhMYyiAYg0122Xa4iicVwBg0Vw38mL/gdnAT5YeGbhuz1cLVv5sh3mGHX
HFcmGx92GimgBHdiQkXsyJ2IzkBOZicyd95LZTF3PRf5MNC9ojtDV8BlahwsM6w=
=pzjL
-END PGP SIGNATURE-

php-5.6.23RC1.tar.xz
SHA256 hash:
235e66d347e67efbbad1fcdc82e754e13b1deb94a85a38b2bf2a2275b5d6f01d
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXWnROAAoJEMK/C8Qzz8iz1s0IAJNHcVFmVQaXQK6K+Fd4L5iT
qAF5RLfXxNHgnfAHwT+8KLr/cUcixdpsmFh31baFJeqRCSYHFV20+57jf7eOZFLM
5MBs8U86Pfkpyuw7U28fDuyfeuOSqd8ZilMoRUCFIRpTCtQ+e1DYGXdYzS6ckIkz
vT4UqenYL6Wj++03qaL4a68RkkcNB/fep5Lqy5rIrU7s6cg+Zii9dJvg/Iw5tiX+
KkafYB2R9ZRQnZgitGeu/65yHfbHJ66DiGdoQkn7E7obkXubH2zhJKxDTj5M8313
xwm6dNleKC8+WG2JG4W+XER6vGpMcWdwjRFUNkki7qKrQzpJ1nJNtEh9o7eSk9s=
=7nZy
-END PGP SIGNATURE-

Thank you for your support.

Ferenc Kovacs & Julien Pauli

[PHP-DEV] PHP 5.6.22 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.22.
Several security related issues were fixed in this release. All
PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.22 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.22

To verify the downloads, you can use the following information:

php-5.6.22.tar.bz2
SHA256 hash:
90da8a80cc52fa699cf2bfa4c6fa737c772df7c92b81ef483460aa3b1e9f88c6
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXRlRnAAoJEMK/C8Qzz8izoYoH/jgTuX4tvLZbYlOpfwXN6Xuf
+V2x9fPIjh/SaNk+S4+GtsT4pwV/IOiOYoEjvqO4CJ0XBZvu3A1h3RcphG/BX6Pi
8c5HpRnBfArlPVvxUsy/ybnZNK2NsnzE/PoZ0dY47WPFO229+b+X95KoCRHQZo1V
UqZtnySWyJM0CBkyw3y8BCyQaEId+Pvcb+wLjgwWzx9goVGOv52JN0ZlCODkTKEx
SpknByKritU2lLy4LjzrZZAekkVggIeswL72r6QRv+RRfJ1frvnGW4eXDq1bkXh8
WPJBk38KNDhkof9Y7AbZopd5QWLvOtsV5ISgIjBKOBHGg2ViclBlsA2EahPoZzQ=
=HUTf
-END PGP SIGNATURE-

php-5.6.22.tar.gz
SHA256 hash:
4ce0f58c3842332c4e3bb2ec1c936c6817294273abaa37ea0ef7ca2a68cf9b21
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXRlRtAAoJEMK/C8Qzz8izUi0H/jvj9M7Cq5uFJYRwTWCxxe0s
v94nD5MZih+WHxmwlil2MoPgkG0qqBaxk1Tijo23H+/98JSS9WNJZOmvCW56CN/D
GAA0xAizIy5VMjYNVhjRm7mscPgzltEUJIO7O7NmyFhlUyyAlKCdyjSh6n9itrsY
k/bNPmSFoopx2N5QtuLXtMkF5cN+7mT7ssWFjyI6sq90gQwtY7ICjDxWnhdBheBO
LwKYRZgNLun1eqwDAHpHTmtY3w1sHANtmRkvzUy/3pmMRzOvCnn/CE+v1VAEzrts
bPnoU5ijPrP8g8+HurfZMuhhjA1UHrI5NoKbXYnXLjVb/Lq4RuL5UTiDxTvR2Gg=
=H7t3
-END PGP SIGNATURE-

php-5.6.22.tar.xz
SHA256 hash:
c96980d7de1d66c821a4ee5809df0076f925b2fe0b8c362d234d92f2f0a178e2
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXRlRzAAoJEMK/C8Qzz8izPzgH+wVYgLp9AEANgs7xtIioufvz
9C8H84l+U/zMiZsNtXgbErCrA/3QuiCZJmgaPKX4JHjP1Riyxa+zeqlQQHkyFQVi
IwO/RrEuZkHBnJGrfk1q0TitA4XsGfwGCOLGaI9mbVSHmAzIGhoAfud+1rFG62hR
LWiutckrknfAdvJ8WDqBTfRHYjzJ5/SktlSkG8h1CSRVKeI9BIyCozehCYl1OyH6
W129/tGqeUPG+AkQCDaPwa/CEH6Q30yOBFMxDsYza+7qaXVmarp/eOWdlSQLXLor
IxG5gocZyfIYVuEwAlZLELNVoKtDk3gaL5PtLlLDGl+SxPsZjo8vF0gB8tuG6ao=
=zpA4
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

[PHP-DEV] PHP 5.6.22 RC1 is available for testing

[Ferenc Kovacs]

Hello everyone,

PHP 5.6.22 RC1 was just released and can be downloaded from:

http://downloads.php.net/~tyrael/

The Windows binaries are available at http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-5.6.22RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for May 26th, if no critical issues will
be discovered in the RC.

In case you think that other projects should also receive this kind
of emails, please let us know privately, and we will add them to the
list of projects to contact.

To verify the downloads, you can use the following information:

php-5.6.22RC1.tar.bz2
SHA256 hash:
ae2a41f5095840cd0f3e7368cdcf22bad5d1de2a243c2e0ea61237732e4a3d6f
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXNPPrAAoJEMK/C8Qzz8izShIIAIwv7vE4lHTRVSHRqkm0CuyN
RMONIaeYStJGExbMzz17Meb22klGE5zQI8yytODY48Oo3GrP6rUcXIITCkNoMd7m
b7i/eXVfDeGnKVdf3GLEMk/dlUN4sXoMZy6dUiytIoDRoLDU9dP0QP+qxKumLjwH
/3nRT1BN9cWvaufrZsDNvhFHlGFj3/8S1TGQqrnpZQ8suQWEtD3tqM8nJgT9rgFQ
segFA2REjOcHeLxYWHocq07u1QheG4DsFbx4BAG2JVP6ogUrqTXD86OUna44Cay8
UCF7zo8WqEdb0gKKifjw70XflNHdEk7FDBQ0yTYG/WW3jH7K70mRe+Zru2EOnTM=
=2fyi
-END PGP SIGNATURE-

php-5.6.22RC1.tar.gz
SHA256 hash:
bfa217f342955da9e13bca523b2874e178cfd6ec7e4aa70a5128696c19146aa5
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXNPP6AAoJEMK/C8Qzz8izTKYIAIgclMnHfe0MM0103RH2vaTS
DYMu2cqcXaoYS06xoOAs6dxbDM6x/RzkLUu31CpdNj0ISjSyAh/yBNRDH0E9xrHT
4ftj5NbIuIEkLpHvYYDqO05RcGnIqZnaB5eOAAQkhHku9g2buasYT04R5Ey60YiJ
vx05PUzshuhjsn8NSkDvLTUToJhaLFkTpCBYFUcgs+ER5Q78b/SGeo1haKBK4m9J
fZt+Hx5dt8gJYOqEjzEUYEcqYgmcDHn97Oc2RQpDId9uC/KmGEDzO6K3E+3USZXo
1YGCxGZ3itG64ZO3zvsBhAXIM276l0GKWc0U41S2127LJ42qss0q7zyRuSrsWB8=
=J4II
-END PGP SIGNATURE-

php-5.6.22RC1.tar.xz
SHA256 hash:
af33b43b4cadfbaef738452418b83ff1d3a503e91d3ef748c73924f0f82cc0b4
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXNPQCAAoJEMK/C8Qzz8izaL8IAN4K/8llLXTw1KH3OIQz8pD4
M1c9VYGOJ6jE/O2I+MI+kT0Ux/XY+YybtbN+rgADwKAehIgQYJCYu+Pai6MeYyx5
M4sZdTQZ3QUOmfK756utK2+tMcq8wY3D5ai79iQCIadO8FBGkhjSY8oUfMjZxHK+
8dRITfMc4xIjrvx6tPZ/g8859q0RM2zN9bVuIjCfMNNwgf3sbyqw86FstGWKx8v5
D4cOw97TanI49MI5aghpr2OEmwgAIkXPz752XqEi6O46WyCYF1sxqlpoB0i+cq04
XJdrAgp5qsdbBLE5BhujiJ44FvMw8eaIOVOf1jp7G24M60NXT8P0W7t7J3d76wo=
=N14c
-END PGP SIGNATURE-

Thank you for your support.

Ferenc Kovacs & Julien Pauli

[PHP-DEV] PHP 5.6.21 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.21.
Several security related issues were fixed in this release. All
PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.21 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.21

To verify the downloads, you can use the following information:

php-5.6.21.tar.bz2
SHA256 hash:
b4ed7ab574b689fd6d6494fde954826c06efc85c505e017b8d776c7c7f479590
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXIWBaAAoJEMK/C8Qzz8izzusIAKqR1O63BCrkmL2M4BEtz9on
HHFAR8nGRK8sqq74mwvlOjNI+bS3QRwkOpGpS1OKnPOc8qcjLRh/LEqKjB32PXx8
jcrLO3eJZyhXqaAkjq+2mDjMeOHKrV+tyFoHAhB/bMTXW8q26mZvi7NS30YyBHB2
9aAK4fnuK7f+ERGS9M6652j1kXw07Rr9963eHQ+bgFLCykdiO4GYfkOpxlfhij2+
EdPpcFYp3zvRLozrs0Fm8gOUwjOXhb9Y9v53mzFNOH1kPPbWk8U12AYPSlaLNpW5
cs7gYVJ7ZCpd9rhJ/Lm/AENpvKffuJ1SibWjkkCxVC+IVcmH4ry8ecc9uu4qR68=
=Muah
-END PGP SIGNATURE-

php-5.6.21.tar.gz
SHA256 hash:
5997668c1f6f2d86a59cf75cc86b4a94687884614dec481fad7e13a76b70fcd5
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXIWBoAAoJEMK/C8Qzz8izuCIIAJu69PXsjiFme0Un0SFH9Yzi
DmXuV13DDZiA+KXBGAFYyCR5YZaPFJLiBnMsVmU2gqFsdn2C2udfDiC8S0B/CLfT
MhdUcA83NmtIfGmzaSRuwWEiVPLnforhTom+221n1yuesR144rEo7w/0fVXvJoAT
6xq0OWWhe5zue5snKrqaU+c8cY0yuu+jWJQTLgQpYpmubU1S1FcvU92NQBYqUksa
Vx6DkeZieTCYrTNRM+BHp9JHE8kWs4Z8oezB6emQgrjWaGiw19sWIKx9b4ZbDzJt
YimpskCkBF/ulIKG2qOw4nVeT3EvbYmg+iFraEgLRGMgw2mIxSr5G00HVwmUsCw=
=pVhm
-END PGP SIGNATURE-

php-5.6.21.tar.xz
SHA256 hash:
566ff1a486cb0485ed477a91ea292423f77a58671270ff73b74e67e3ce7084f9
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXIWBvAAoJEMK/C8Qzz8izxLMIAKAPFnuEgbgBVmVK5wrZg8NG
Kd9e8qq+8QC/7RPUhjr2/6ySRP0quRAp/nK2ncjWDVavgu59GVgoap9iIV5EZzwo
/MurdkxhxPWG6qwnG36+sqfEBii5JGuKpwFOypvrau2tBH8A7CAvrDwCgkR5gPfx
wjJjK6IuxSaI7xPXa8pKdK4TKUyNEwBZ6AGl2tt2Ql3x0FM+2nBFcpKZglIp0F7P
CXpj3Hfm1o6kT36mHGiXDTlVaba31vME/KQGTFB+90mLvbPy4Zd5mUBNcdKP/Avz
u8A7OynEzeD+e5+zTul7k9Zv/IghslR0hukjuPQ+HHBlHX2QuT3FI5Z+kTpFqw0=
=Bqqk
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

Re: [PHP-DEV] PHP 7.1 roadmap

[Ferenc Kovacs]

co-RM can simply mean "one of the two RMs", and emphasize that somebody
would volunteer to take the role but not being comfortable to doing it
alone so I think we are on the same page.

On Fri, Apr 22, 2016 at 2:50 PM, Julien Pauli  wrote:

> On Fri, Apr 22, 2016 at 5:03 AM, Davey Shafik  wrote:
> > I'd interested in co-RMing 7.1 if someone else wants to step up also?
>
> Hi.
>
> The Co-RM is the version-1 RM, so it will be Anatol, RM of 7.0.
> We are looking for a "master" RM here :-)
>
>
> Julien.Pauli
>



-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.21 RC1 is available for testing

[Ferenc Kovacs]

Hello everyone,

PHP 5.6.21 RC1 was just released and can be downloaded from:

http://downloads.php.net/~tyrael/

The Windows binaries are available at http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-5.6.21RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for April 28th, if no critical issues will
be discovered in the RC.

In case you think that other projects should also receive this kind
of emails, please let us know privately, and we will add them to the
list of projects to contact.

To verify the downloads, you can use the following information:

php-5.6.21RC1.tar.bz2
SHA256 hash:
098cbd59b9c1a67154038dc3641497581afb85966c9599c84e8acd4cfa040fb0
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXFzo/AAoJEMK/C8Qzz8izX3AIAJkoZLwqeRXp4zVGQMRqo4dm
UFWYJFPS8iwfzagVQu004NSn8KpjIfTn7S5W+htPH9/wjG44otch3VwcIA7oeCmR
/8yqG904BGSe8bv6VzzOcostofKs29t0J8Mvne1JQIBZaXZb+zRGUK5K2w/M1FWa
uM1tao1gADphqzETaW9HY3fPJokORWSKdisHt2/bGY7iFJplAaN29s7zoZsLyFdJ
rsByAoBF97C6NTNcMavQJ2odvWwBahfLKcBTT6bNAYq//aLwRUtH0l8jjstHxUkx
ctkAVo/pjIJ4jrDa2yhJyMAZN+sfqjmCpcMgvuR+KlA3uGK6f1vrwAPWUgU2+bw=
=tPtO
-END PGP SIGNATURE-

php-5.6.21RC1.tar.gz
SHA256 hash:
3328a41c45201e0e8cb61dd8941bac498dbb70d2d555e417cef8f60f5a9f64a6
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXFzpEAAoJEMK/C8Qzz8izUYYH/A9jC094IFims8KGm+T9Y+7t
Pndp8bdczLL+2Tcaze4+RBeo/KiYjmSFaDiOy1sH/rc7w2r/J7Fqt6w3SPAGHGGB
kJfmweAJDHvmsqRAZLtW0lby8nMx4EZvvMz6YJektzEioM3MFPUYYfkQrF3HeRAZ
j7tXYH3FQ5hkcOI0vPiDjq2Ex/ZRdT5w4Vxt5INIs+JhXgE8QuZEKmLm+Kp0Rqfx
S7XSYno1xeko92Yaigf+qYQWzw26y/cxK4EhmRWrF7Zjs3o58thLl05BfjjaLuLD
3oFKTNo+PEZeyNAOR5TjoxMo3RHnj5NRUE0qJQyyPi+PwIAJvj0ZaqlHO7kPa/E=
=pAe3
-END PGP SIGNATURE-

php-5.6.21RC1.tar.xz
SHA256 hash:
664da21306560d5b385502e814f5f06f4cc3a1eb842ad01ce6f897e2a1a7f619
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXFzpJAAoJEMK/C8Qzz8izbLcH/3uHLuKFnt1HoYU4x2dHe2FI
+SbhZpEsWpxOAKvMgUQ2g/yX9qStMr6f2WbAiM1gwpklpf1zi+8atIHF3/dTDAIv
ORdfKf83f7U2hiRpUd9Madd9XWEZ6q45PmEtsKV96IahfqZHney+WeV/cLcELg/E
/iekdCoB5slagAwt83h/nvJ7f+qaJ34KTWcjNEVj4HSQzA8SFV0RgAGmnQHWY8oU
wmRLTl6vOUcCfxAjFh+p5jnG6Y+m3qgsfItEgwfFJ4goMQT64M6w2j+n8F9DuGN7
Kao+EFJZSg5KqKViK0aJ8/Vz/tuoyj3lk3CE3m+wafSjWkuTceDg5ogLb8TpUNs=
=giOn
-END PGP SIGNATURE-

Thank you for your support.

Ferenc Kovacs & Julien Pauli

[PHP-DEV] test

[Ferenc Kovacs]

sorry for the noise

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.20 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.20.
Several security related issues were fixed in this release. All
PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.20 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.20

To verify the downloads, you can use the following information:

php-5.6.20.tar.bz2
SHA256 hash:
5ac7bf7caec7a79b18cf458e786fd1609ad2da771224b80bc15cc6f01b22bf1f
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJW/Gv8AAoJEMK/C8Qzz8izl3oIAMmSbWOdtIqL0n1siQAvPFCQ
zvV7UhO3z3LKZnMCzFpIz9l1Sa078gWwaJ1IpRWazhsIhZNfnBw23a64jsNc0RTt
bsirevyleOH2jRXISkKlMbVMPkvWtHyptQONAtO/wlGYNHqjCUeA1WOMEzpVtCQb
WbSVRgv8UOdvERYaPdnpWbm347ME1nLSeGeHX342bAsQzoQhy/CfALra12VyQ2Z8
9E30+5jCwKKC4dqWDNWzVqqL/2tcYpCYrx1fC97Wc8lfambGDltfisqputdh94/Y
j1Bi2KsR4YtkqxocSOrUb+EDJmAUoywt+TUZ4Ik48Eez+/oAd7vleF08184iTbU=
=q+Nh
-END PGP SIGNATURE-

php-5.6.20.tar.gz
SHA256 hash:
9a7ec6e1080ee93dcbe7df3e49ea1c3c3da5fc2258aff763f39ab3786baf8d56
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJW/GwCAAoJEMK/C8Qzz8izxAoIANxMhkIfMPmyixVnEu329g5z
oPVh383mzEyLuWjEvB9kPiZFhFh6F1RnWusS+oQ1d2i1h1dw6YUp5vdPsAC28b7o
fIHfmQ6q4bgpGTmElkCRpBFdHgSOaI3HSB7eZtMFifBJWrZwTcmKII/M+r+46Iiu
JsNmG401uQQwO+Cbl6PZKpQ/84I+WwZT/fDWTLFaAVprw2Ygc4AsHliGHxr89Flv
ecg1gt+KACjCUG85yhuYf0DANtN2vzrCkr3xzLq5DOk15nctut7a5ewOSRugMNSj
TKs+7IfplO6/CV/YmBnh8Pfdm8rvfrqaXohLf1oppsFblwnJI3h5tDSiFlVUJTc=
=kiPW
-END PGP SIGNATURE-

php-5.6.20.tar.xz
SHA256 hash:
2b87d40213361112af49157a435e0d4cdfd334c9b7c731c8b844932b1f444e7a
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJW/GwHAAoJEMK/C8Qzz8izX84IAN+mTg973KfUcfvByxMAR7wR
HXNYVWdnjvyiQGDGxaLzjhuUE+u3jpwBv8gDH6rZk488AM8BeQDCrJWO/011r6wZ
gOLuCRCdKfwSJ2A3+TpeRha0WE2fDjpbWU9I2RbFBqrb7KHQp9XsHxivHj8NPhxA
sitP7PfT/a0t65E7ThoVIn1RvDykEx/TrnxBgdnAsVrmIsLz/WnwyPhzfoNFHoYy
HeMiA+lDdL8Duwo9fgEh0sMhY9+pqR0ALKu9kscRQuLkRoaZE+Eo+9OEsGOqEl3g
+XS/TRpYP5bWx96wIJc4+AGsBx1LuXaFitaaAodR29kRaIJQQBluIIklW4dbwkY=
=ynp7
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)

[Ferenc Kovacs]

On Tue, Mar 22, 2016 at 7:09 PM, Scott Arciszewski <sc...@paragonie.com>
wrote:

> On Tue, Mar 22, 2016 at 1:41 PM, Ferenc Kovacs <tyr...@gmail.com> wrote:
>
>>
>>
>> On Tue, Mar 22, 2016 at 6:00 PM, Scott Arciszewski <sc...@paragonie.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> https://wiki.php.net/rfc/mcrypt-viking-funeral
>>>
>>> The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is a
>>> 79.3%
>>> favorable response, which exceeds the 2/3 majority by a significant
>>> margin.
>>>
>>> Thanks to everyone who voted or participated in this discussion.
>>>
>>> I've heard and respect some of the objections raised by folks who voted
>>> No,
>>> but moving this liability out of the core into PECL as soon as possible
>>> is
>>> not only a good move for the security of PHP applications, but now we
>>> know
>>> it's the choice the community wants.
>>>
>>> As promised, I'll get the E_DEPRECATED patch written soon.
>>>
>>> Additionally, I will have a decrypt-only mcrypt polyfill project written
>>> hopefully before 7.1.0-alpha but definitely before 7.1.0. This will allow
>>> people to migrate towards something better, e.g.
>>> openssl_encrypt()/openssl_decrypt().
>>>
>>> Scott Arciszewski
>>> Chief Development Officer
>>> Paragon Initiative Enterprises <https://paragonie.com>
>>>
>>
>> You ignored the voting process and my headsup mail about it, and also
>> ignored most of the feedback from the replies.
>>
>>
>> --
>> Ferenc Kovács
>> @Tyr43l - http://tyrael.hu
>>
>
> ​Let's go line by line, then?
>
> 1. Email internals@lists.php.net to measure reaction to your intended
> proposal.
>
> 2. Get wiki RFC karma
>
> Already had that.
> ​
> ​3. ​Create the RFC
>
> Yes, obviously, I did that. :)
>
> 4. When your RFC is ready for discussion:
>
> * Change the status of your RFC page to “Under Discussion”
>
> Check.
>
> * Change its section on https://wiki.php.net/RFC to “Under Discussion”
>
> Totally fair to cry foul on this one; I did not do this. I wasn't aware of
> this step, otherwise I would have.
> * Send email to internals@lists.php.net introducing your RFC.
>
> I did this two months ago.
>

As I mentioned in my mail in the voting thread I couldn't find any email
from you to the list with the link to the rfc, still waiting for your reply
to show me that mail.


>
> 5. Listen to the feedback, and try to answer/resolve all questions.
>
> ​There were no substantial questions that needed to be addressed/resolved.
> People expressed concerns, but if we blocked every RFC because someome has
> a concern that doesn't form a substantive question, would we ever get
> anything done?
>

It was brought up that the rfc should be clear about what it is targeting,
voting shouldn't happen without an explicit target version, as we have
different rules and expectations for a minor than a major version.
For the record our release process rfc sucks a bit in this regard(
https://wiki.php.net/rfc/releaseprocess), because it states that BC breaks
shouldn't happen in a minor version, but it explicitly allows moving exts
from core to pecl even though that this could cause userland impact (for
example ext is moved to pecl then some internal API is changed in the core
(which can also happen in a minor version) and the pecl extension doesn't
receive an update so pecl install won't work out of the box). This means
that technically you can target both 7.2 or 8.0 with your rfc for moving
mcrypt to pecl but people would vote differently depending of what version
do you pick for the rfc to target.


>
> 6. When discussion ends, and a minimum period of two weeks has passed
> since you mailed internals@lists.php.net in step 4, then you can move
> your RFC to “Voting” status.
>
> Two months >= two weeks.
>

see above, nobody seen your rfc page or commented on it before you linked
it from your voting thread. Heck, as far as I can tell, it wasn't even
listed on https://wiki.php.net/rfc before you put it up for voting.
For the record I would probably vote yes for this proposal regardless of
your answers on the feedback, I just want to have the process followed
properly.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)

[Ferenc Kovacs]

On Tue, Mar 22, 2016 at 6:00 PM, Scott Arciszewski 
wrote:

> Hi all,
>
> https://wiki.php.net/rfc/mcrypt-viking-funeral
>
> The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is a 79.3%
> favorable response, which exceeds the 2/3 majority by a significant margin.
>
> Thanks to everyone who voted or participated in this discussion.
>
> I've heard and respect some of the objections raised by folks who voted No,
> but moving this liability out of the core into PECL as soon as possible is
> not only a good move for the security of PHP applications, but now we know
> it's the choice the community wants.
>
> As promised, I'll get the E_DEPRECATED patch written soon.
>
> Additionally, I will have a decrypt-only mcrypt polyfill project written
> hopefully before 7.1.0-alpha but definitely before 7.1.0. This will allow
> people to migrate towards something better, e.g.
> openssl_encrypt()/openssl_decrypt().
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises 
>

You ignored the voting process and my headsup mail about it, and also
ignored most of the feedback from the replies.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.20 RC1 is available for testing

[Ferenc Kovacs]

Hello everyone,

PHP 5.6.20 RC1 was just released and can be downloaded from:

http://downloads.php.net/~tyrael/

The Windows binaries are available at http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-5.6.20RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for March 31th, if no critical issues will
be discovered in the RC.

In case you think that other projects should also receive this kind
of emails, please let us know privately, and we will add them to the
list of projects to contact.

To verify the downloads, you can use the following information:

php-5.6.20RC1.tar.bz2
SHA256 hash:
4922256a87f78417345e2a7f107a3d7997b671332eaee0f5678dda985e883f86
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJW6zDhAAoJEMK/C8Qzz8izmecIAMuV9R2HBbMz96Fk/pGfx9qO
VwB2YuxPIfHMrLcabIfgyZP3QUB85+vPgV2bi74rIZlthiofpki62EVV6n1sUY9R
xGkyQboObz/r4J1wfUPDnujTJB9QZct798OrbDc57QU/dh2CUAWhLUN+IhBn91ar
BOsUPoQSoT/do7hMSQ3HFDof6g//f8nNKqeZ7EWYMzTqfI7booR8HKQn7FROkbCH
+/Evr9fiOz7F6AUv2yIAYOM5RFvP6L7RvV6E/xzN/Awwu2L4N7eGEpB3y0oJbz0B
evwUbrdIXBFgd7tiJqxOhykpkTbOSZozYRPwF/7W2gHR2x08dI3ZGFZqCnNcgcQ=
=3UxH
-END PGP SIGNATURE-

php-5.6.20RC1.tar.gz
SHA256 hash:
94d2c528e9c6c715e67ffc4156ba3169e0e2b57b8fdda1d26c32a8bf4546ab6d
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJW6zDoAAoJEMK/C8Qzz8izznUH/1M/EDfazOmDBDMKivdKB+PI
jKjjtvtgtY9MPOSq0eD5WugGFHdeddlag8ajh2F10/Kzs+sNyQmQxbm5aZErAltf
/k/U/Go6zBgu0sRtwUdqoTLm0+Y4FtVI6ua6l96N9P4Z7PUCp0omSyFRBhNmBZHt
u23a3DnLqgLu1Id5zbRL4O1JAgicLSZzYqEk2TW0qgggyHmJwsU49LohBk+yiUkm
5ToSyBQPpc0lGOHUMrDNDCXO1r4y0veFXFsR3xIeyqitutG3RNR4UUY58XL5Km6e
N9KE9GqRIYi/SKvBUz5cB+KTZW5V+D/YHPpF8NinLlYslGRIYeSf7Ettkl3+SuM=
=d7Mo
-END PGP SIGNATURE-

php-5.6.20RC1.tar.xz
SHA256 hash:
80f56bd89d15d55a7148a2a0c36ea610994700aa5052e397b001fd509ff90bf7
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJW6zDsAAoJEMK/C8Qzz8izfrgH+wSCsQYHXYt4dro/q94DbVt/
8YNGJzYqJqaHYyx8oYbNIAmLiem0Hy65kqid4aczLYuqm14UDESvHUcdh/BbwdO+
0pjAhFnvwK749VZJ7TcmpyRnIddVUs/JnFopGvBVX6skKN+Yo72LtpscaXLAw/3J
XsrPbrVACI8GJChNVPWBTXynz/0z2BbrbRQ8TSLtbVgsiq7PPFr2UaaKFjwDv6lq
OtB7GvDLyCw4ZnF43ufZ0POm5BG9J6hqZKL/ZW2Lwe4IrxgAnqqY2gmFCvTxp/DA
fwANdFkHnuqQOwVV9fpltHwQJghkvpjg+J3btM/6x4fWmvT8Bs+ZqO3g4qJ3HOU=
=hkut
-END PGP SIGNATURE-

Thank you for your support.

Ferenc Kovacs & Julien Pauli

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt

[Ferenc Kovacs]

On Tue, Mar 15, 2016 at 6:13 PM, Scott Arciszewski <sc...@paragonie.com>
wrote:

> On Tue, Mar 15, 2016 at 1:09 PM, Ferenc Kovacs <tyr...@gmail.com> wrote:
>
>>
>>
>> On Tue, Mar 15, 2016 at 5:11 PM, Scott Arciszewski <sc...@paragonie.com>
>> wrote:
>>
>>> Hi PHP team,
>>>
>>> I've opened the vote on https://wiki.php.net/rfc/mcrypt-viking-funeral
>>> which aims to deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1
>>> (i.e.
>>> make it only installable via PECL).
>>>
>>> In the interim, I'll be developing a (MIT licensed) decryption-only
>>> userland implementation of the mcrypt ciphers so people can migrate their
>>> code towards something better.
>>>
>>> This vote is opened on March 15th, 2016 and will close March 22th at
>>> 17:00
>>> UTC.
>>>
>>> (Sidenote: Apologies for the brief unannounced hiatus from participating
>>> here.)
>>>
>>> Scott Arciszewski
>>> Chief Development Officer
>>> Paragon Initiative Enterprises <https://paragonie.com>
>>>
>>
>> hi,
>>
>> first some formalities:
>> please make sure to follow the process stated at
>> https://wiki.php.net/rfc/voting
>> New RFCs first should be proposed for discussion and it would require a
>> bit of vetting before it can be moved to the voting phase.
>> I can see your thread "mcrypt extermination plan" but I can't find any
>> mail linking to the rfc page before this one instantly moving it into
>> voting phase.
>> I would suggest cancelling the vote and waiting a bit(I would say 2
>> weeks) for any discussion/feedback on the rfc itself.
>> Personally I also don't like going with the minimal one week voting
>> period as it is too easy for somebody to miss the chance to vote because of
>> vacation or just a busy week.
>> ​​
>>
>> I also wanted to mention that some of unsupported ciphers listed under
>> https://wiki.php.net/rfc/mcrypt-viking-funeral#backward_incompatible_changes
>> can in fact be supported by openssl as it(openssl) allows the usage of
>> plugable engines.
>> --
>> Ferenc Kovács
>> @Tyr43l - http://tyrael.hu
>>
>
>
>
> https://wiki.php.net/rfc/mcrypt-viking-funeral?do=revisions <- already
> been under discussion for a while
>
> ​> ​I also wanted to mention that some of unsupported ciphers listed
> under
> https://wiki.php.net/rfc/mcrypt-viking-funeral#backward_incompatible_changes
>  can in fact be supported by openssl as it(openssl) allows the usage of
> plugable engines.
>
> Can be supported !== is currently supported out of the box.
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises <https://paragonie.com/>
> ​
>
>
sure, but I still think that it would worth mentioning the possibility
instead of stating that there is no migration path available for those
ciphers.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt

[Ferenc Kovacs]

On Tue, Mar 15, 2016 at 6:10 PM, Scott Arciszewski 
wrote:

> It has been "under discussion" for over 2 months. I just didn't know I
> could edit the RFC index page.
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises 
>

https://wiki.php.net/rfc/voting#proposal_initiation
you have to announce/propose the rfc on the mailing list.
as I mentioned in my previous email, I've seen your mail from 2 months ago:
http://www.serverphorums.com/read.php?7,1382467
but that did not link to your rfc page and I don't think many people just
had the luck to find your rfc page without the link so nobody really had
the chance to actually review and discuss your exact proposal.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt

[Ferenc Kovacs]

On Tue, Mar 15, 2016 at 5:11 PM, Scott Arciszewski 
wrote:

> Hi PHP team,
>
> I've opened the vote on https://wiki.php.net/rfc/mcrypt-viking-funeral
> which aims to deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1 (i.e.
> make it only installable via PECL).
>
> In the interim, I'll be developing a (MIT licensed) decryption-only
> userland implementation of the mcrypt ciphers so people can migrate their
> code towards something better.
>
> This vote is opened on March 15th, 2016 and will close March 22th at 17:00
> UTC.
>
> (Sidenote: Apologies for the brief unannounced hiatus from participating
> here.)
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises 
>

hi,

first some formalities:
please make sure to follow the process stated at
https://wiki.php.net/rfc/voting
New RFCs first should be proposed for discussion and it would require a bit
of vetting before it can be moved to the voting phase.
I can see your thread "mcrypt extermination plan" but I can't find any mail
linking to the rfc page before this one instantly moving it into voting
phase.
I would suggest cancelling the vote and waiting a bit(I would say 2 weeks)
for any discussion/feedback on the rfc itself.
Personally I also don't like going with the minimal one week voting period
as it is too easy for somebody to miss the chance to vote because of
vacation or just a busy week.

I also wanted to mention that some of unsupported ciphers listed under
https://wiki.php.net/rfc/mcrypt-viking-funeral#backward_incompatible_changes
can in fact be supported by openssl as it(openssl) allows the usage of
plugable engines.
-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Can you please give me karma? Understanding Karma as a Buddhist

[Ferenc Kovacs]

On Wed, Mar 9, 2016 at 1:07 AM, Midori Kocak  wrote:

> Hello,
>
> You remember my question?
>
> A question about null coalescing operator..
>
> $this->request->data['comments']['user_id'] =
> $this->request->data['comments']['user_id'] ?? ‘value’;
>
> …
>
> And you remember my pull request? https://github.com/php/php-src/pull/1795
> 
>
> So now I created my wiki account after I figured what was the email thing.
> And one friend suggested me to write here to ask to have Karma… So can you
> please give me Karma?
>
> Meanwhile I will be praying in front of my Buddha statue.
>
> Midori
> http://www.mynameismidori.com 
>
>
>
done, feel free to ping me if you need further assistance.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.19 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.19.
Several security related issues were fixed in this release. All
PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.19 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.19

To verify the downloads, you can use the following information:

php-5.6.19.tar.bz2
SHA256 hash:
2a24a3f84971680ac0a4c71050067de4f76ee235aa4a041fae21bfa69975c168
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJW14l6AAoJEMK/C8Qzz8izU9AH/3gI4tAMaafzR2jBxqaSCshg
mVEtBDeV7MeSmrIL0X9HD2k2Dc7LJ9/6tLijMO+zUc10XjagfOrh3nEnTXyGs11G
UvNgaavG6TR20w8OqBBHHoss5+mie7qde42IyBUO5w8OhP2hfQG2B1pF47bce/6m
COu36n7JGeW/Kt7OiFbZdTeXyNQlrNmZNOx9lictPmG12V8t5a2A17zH98bqL+AE
+VDQREqlwfU8Z5D9QMG9CT69nyMDCVQ5TF8asJJckYJKeIYt+Fa22gD4gqY9pB53
+ZhUaIM+XzgZXtGsO9yA+R1R8KrNFUvoBpwcEMVep0M1d0XJIOi1LuXTk5KR+UE=
=oQdV
-END PGP SIGNATURE-

php-5.6.19.tar.gz
SHA256 hash:
fce49cddac9337f0c83afbafac5acfb82ba9f876a5a880c88240feac8c9b7a22
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJW14l0AAoJEMK/C8Qzz8izZvIH/iDJ8x82/D3w4iYg7ewYhaC9
ZUbIGpH5gus3vjG8Db68+fJqdDhMJuJa2LBRdG0czYq+Kacmw88ZkTXLuaOH/QtV
/iPNEfBNcRa/FCUNBgpLMnNyogWMk54IbtwnxrO4ZWAS44tFrckphqyL2NAkwouP
22+HzyCcaK2dJns3Rt5B/A+rKbQr3TSRnhAOpsY9bD+tM5BVF0q0O7BPUmwiCeAv
qiRhc0yvDMLWYTRX6gG6vLvWYLxHOqpmDZQVVbjuFfjml9J7iH1R/XDz5tQkxj/b
7HO9xO3fYuhW3CBp++vjYDcBqcKpI+SiGV6k/UMaGD8EuThz4CF+VMaZajrX8t4=
=uq/y
-END PGP SIGNATURE-

php-5.6.19.tar.xz
SHA256 hash:
bb32337f93a00b71789f116bddafa8848139120e7fb6f4f98a84f52dbcb8329f
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJW14l/AAoJEMK/C8Qzz8iznMIH/iKs4wTIGexTP2/6npzwhZ/S
+wQ4IRn3zC7Np1pT5XasRRoGOatfJWxEavT1+4J/RzSNklReUHD/bf7lGafTgOGx
f5AMqzQGYmev3nw41kp6h+ax7WQ3Rwzx3WDjTv3oWeIq0G8dbJdpgC+01zwTZUX2
vSegXtFlIBeXOkLdWg2+wGi/1dQWRvLVhc4pAuSKE6rZPYGIPHE0ynNMogf7SBfh
WOOs/DbmsU0tW3kuGk7cU2CarrwleUe5CMTNw9huWc6ja/mQINDjHjoPTP05bUkY
ML6GOfeMr2aHOrkPS7U8dND0kURGmqCo/16mdrpdf8/raQm7NMl6KxtMgFRa1/k=
=RptR
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

Re: [PHP-DEV] Re: Request for Karma

[Ferenc Kovacs]

On Fri, Feb 26, 2016 at 4:33 PM, Dominic Grostate <
codekest...@googlemail.com> wrote:

> Username is: orolyn
> On 26 Feb 2016 3:31 p.m., "Dominic Grostate" 
> wrote:
>
> > Hello,
> >
> > I would like to request karma for the wiki.
> > I'm assisting Rasmus Schultz with the Generics RFC.
> >
> > Thank you,
> > Dominic
> >
>

hi, I've granted you with rfc karma.



-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.19 RC1 is available for testing

[Ferenc Kovacs]

Hello everyone,

PHP 5.6.19 RC1 was just released and can be downloaded from:

http://downloads.php.net/~tyrael/

The Windows binaries are available at http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-5.6.19RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for March 3rd, if no critical issues will
be discovered in the RC.

In case you think that other projects should also receive this kind
of emails, please let us know privately, and we will add them to the
list of projects to contact.

To verify the downloads, you can use the following information:

php-5.6.19RC1.tar.bz2
SHA256 hash:
54db8746e1b6ba995b685a877b8d4d2fe8b90e90fdc08e1f4cbba6475afd0bcb
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWxwa6AAoJEMK/C8Qzz8izj1IIAOnmGH5gCrElArh8kwxTYpXB
lR47m/UZRsjRTASAqToNvug+YJe8OdjefdgBlSbeFdj9Uyn7D3vks/TApXctbnE7
sPBIT37t3hcbixPrOm52nfMaaSHCs/jPP85gcwSAeNLKZea1M+Sztof74bY6/HzE
BvYnc3FOCKfl55Mt+++UEQv0ZZRhNPmzh9UquOWfGlmh7usbZfEEpkHK18O/1NkN
PF6nAVqAxteBH14EgQ3YswtGgr19mq6EMIYO6UPkpsXLHWgnDvM0U9DUZQ6gtrgq
FG5MmutF0c3QvD3RqD3vtjODjTPWYNUJ1ejmGERgRR6MvJFY1zq6ApIoI+ni3jA=
=QPIc
-END PGP SIGNATURE-

php-5.6.19RC1.tar.gz
SHA256 hash:
a43db1a23a00a4987eba559c762facbad4bef702c65a94238ba493a3f4780bad
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWxwa/AAoJEMK/C8Qzz8izyuAH/0t0RZvOVKD06sFGgWoHTMoV
14kuywrrP4NK4C/6qJqklmr/JIHUwcyn/JZRoJDbKmB+YtvvtTSY7KiKAcVj8GQq
bWCOiOoaI7kBdWi5H6JvvX+/wkhIxsjXPA2obT7I0f/YQ+KON5HZFj2YO3DkVi0E
0Got/KyPjRzGJQXR9BNQsjcZrVVHOceW0CanCIlmyQjXBOEMyN95vPlZqNfRIAuE
JvhRMyNFmv1VCzFfyrofl5P51SxqqwY346doU4yDWCDzi2PmnIoiYzi/5bl6vezq
lPj7DBJ92r2yWJhMXfPCEpOUu9HbM3CjjnQsbdoqkdLGW7y22gfmoh7QMYiRL+Q=
=uDGd
-END PGP SIGNATURE-

php-5.6.19RC1.tar.xz
SHA256 hash:
f931625da53c22bad779e5f30ac8cbf421999f0da1c4ae4c0b15cab96f2bdc86
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWxwbEAAoJEMK/C8Qzz8izngAIAN5s3QQKGUjvzdOHU31nOqH+
zj9xJamYW9C8yZQgwAs+Q1OyGi7mIkz1gzh5N3LlNjIYzuYr+RQubjOfuEsYGO5L
EROjjSArp5ORLZ+gkRogopToOMz9mehOY2IA44ytavcqn+aS++mMzlIRjhdj6mF3
Bsgf8WUUiCZNf6BgQIu0ch0RkiYv7KrF3HtO+wB/0eC+nSeyvEz6GNvyVcn3FmNc
vfADWD8cDUpeZxrOV5CilvO6j8KLR1HW9thRlPzJmvQdQtS6xg8cPrH2On3TMgVm
+zRpsHmyt5PFIlxoiwn6AoLywCRzpnjWP/6oWoG4n3t172U17Dp0rK/jEWB5sSI=
=ZeAl
-END PGP SIGNATURE-

Thank you for your support.

Ferenc Kovacs & Julien Pauli

Re: [PHP-DEV] Re: Karma?

[Ferenc Kovacs]

On Tue, Feb 9, 2016 at 4:52 PM, Matt Prelude  wrote:

>
>
> On 09/02/16 15:31, Christoph Becker wrote:
>
>> On 09.02.2016 at 15:50 Matt Prelude wrote:
>>
>> Where can I find out how voting karma works?
>>>
>>> I've searched but there appears to be little in the way of a clear guide.
>>>
>>> Keen to get involved, but not sure where to start.
>>>
>> Who can vote is described in <
>> https://wiki.php.net/rfc/voting#who_can_vote>.
>>
>
> Thanks Christoph,
>
> I was wondering more, how someone without karma can obtain karma.


you can read about that on http://php.net/git-php.php


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] PHP 5.6.18 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.18.
Several security related issues were fixed in this release. All
PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.18 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.18

To verify the downloads, you can use the following information:

php-5.6.18.tar.bz2
SHA256 hash:
c3cd4a29a9562309d36e2b128407d6eaa5c7dde590d2b1a464457383e517f4ed
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWsd5YAAoJEMK/C8Qzz8izqH8IAIvujyqRgV4YjWiQwAApRZpa
po8dBFnf+MDMGzsS+Rxoq10ZrwTzu5C9vytfsxh4ICILg94LMBtoHf8iqHs0xHuL
TkXCnlVQYMjzj7t1+T5g0UGWPWwNw266xSlqe51ai0qAF1PqmCxoeGz2y0NSYXzu
NstpAO9SH/OzbPGP2sTdgVUZC9527TB2kJ62LapGDYoqFbFoYh+OBmfZZazEOQxh
AqpxYQDECkw2koCDgmquCRLkF/Yfj++hMUsWzUCU7pExZZpOGmb0e3uUT50yKJ+G
BRImIJHn/kds/TGcxzuaVBT9Fl6BcN/jyNkwz6NnfgclI5XOIWhxhgkTjQ5K1f0=
=EWSF
-END PGP SIGNATURE-

php-5.6.18.tar.gz
SHA256 hash:
76da4150dc2da86b7b63b1aad3c20d1d11964796251ac0dd4d26d0a3f5045015
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWsd5SAAoJEMK/C8Qzz8izyXwH/3w14IZClJP1t6GbEBP517CN
Onlc/2UrAsBFR3gWANLg49CWVV064ftO2Fz2q+OsaXbBvxPT2SWL5b2Nlwinm0bJ
b91YvjbiJ6DO/4uioVeTX0FrOATG0QidxdqLYVS/UOcHhmS6W7bV2laLLp6paWID
UvH/YeXxgbLWKqB2o0zwJhS0BDVI/+5hks4p9Y4rGlFfa9BPjH/ClsPpjXsdy1Tx
jJiG8dxMBKHvp5k/HwzyfZG5mlX11uSoClrTcneDtrsJ0mPUevPhAl1Ri2e/miDt
hP4IM08SHqjllDHhCZT2L1AiJbNO2GsInizJgLBkKxHW6if7wyqZ22K+a+3TSv4=
=kJrz
-END PGP SIGNATURE-

php-5.6.18.tar.xz
SHA256 hash:
54dd9106c3469bc7028644d72ac140af00655420bbaaf4a742a64e9ed02ec1b0
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWsd5eAAoJEMK/C8Qzz8izhA4H/17QqJH7LpZ1goSuV1EGMpoq
6zpew5YWLKD7IsN+4zcGZSp6RZ/wrMJq+GqEb4zm7mEzuDp18cvPqBIayo+/P+BJ
REBQUSTa66G++17ceRG4FBIChmxDpwM4+8776KIdXkDYL9zihAsK/AcB19oP4YOC
nV32nvPzAsSiO7PMAEuYM+f6x1UzFR+UsWU8pnKN7HoY3jUEJ0RuJEkBjLo+7jzy
nbgMcdATLSak4zxml38ViL6iIqu+ADvzfsKfZF7/a/akjJ5rO/JZybWz1PmRkilC
iYdb+Hh2a3j3/9K1Q0r1ETalG+Xqg/c+KEIKanAKTAmO8gTwTJItpwLJ3VY21BY=
=Ue5M
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

Re: [PHP-DEV] PHP 7.0.3 RC1 is available for testing - **** BC break ***

[Ferenc Kovacs]

>
>
> > This is added because when session cannot be started, then it should
> fail.
> > This fix is related to https://bugs.php.net/bug.php?id=71243
> > The php_session_abort() is not directly related to this bug, but this
> (and
> > other fixes) is added because session_start() returns TRUE even when it
> fails/
> > should fail.
> >
> > Note: PHP 5.6's session_start() return value fix is not perfect to keep
> > save handler compatibility which is a big one. PHP7 should return FALSE
> > for session_start() failures always by the fix.
> >
> > Fixing the broken test should be just removing the php_session_abort()
> from
> > php_session_cache_limiter().
>
> Fixing broken tests most likely mean BC will remain which is not so good.
>
you probably meant BC *break* will remain which I agree that isn't good.


> I understand the overall goal to improve session security but this is an
> area that has behaved this way for years. I am totally convinced that such
> big changes should have (or should) in stable branches, be 7.0 or 5.6.
> Especially because testing these changes take time.
>
I have to look through the changes and the original bugreport which
warranted this change but my gut feeling is that this shouldn't be changed
in a micro version and Yasuo even changed/fixed a handful of tests together
of the code changes, so the potential impact could be even bigger than what
Remi spotted with their CI pipeline.

[PHP-DEV] PHP 5.6.18 RC1 is available for testing

[Ferenc Kovacs]

Hello everyone,

PHP 5.6.18 RC1 was just released and can be downloaded from:

http://downloads.php.net/~tyrael/

The Windows binaries are available at http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-5.6.18RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for Feb 4th, if no critical issues will
be discovered in the RC.

In case you think that other projects should also receive this kind
of emails, please let us know privately, and we will add them to the
list of projects to contact.

To verify the downloads, you can use the following information:

php-5.6.18RC1.tar.bz2
SHA256 hash:
b5a8e3bca56035af6e563bca4b20f12d167da596091d49d54e7daa28d83ca0ad
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWof9iAAoJEMK/C8Qzz8izcDEIAMfJHZ0azmr7bd5Xm3JfflMD
bt/HC/UcxjIWADLmag093wMEw6kjXC8JRwP05fKVOgvgnGyeBJ0SsgkDo6MtE65t
PvqIjl9WvdDHL+q3sMWgEgVAENNMk9fUrecOcgzCsoO2ccSqOeryGujYMOgYaqva
18dK40TVUHi0mTxqLNWuDgTMralwZKLkuks6oq+w52GYHzXJGv/4HnjXY4n2B5Zx
gi4X3uCictZ+ogfVae5aB4nxezoapzLrKfHEjZOpZcD0ng1O2Clf6yCGgn3qXNcj
34Jpa5KPpUmtEyVmdxZdNyiy1oO4T2WRZTYxbX/YAzGMFdCYTq/nVyIhZ5BMSdo=
=lDb9
-END PGP SIGNATURE-

php-5.6.18RC1.tar.gz
SHA256 hash:
d3815549a80e76c5fe1ac6cdcd98e5e08ec33f03ebf0b57a5e1f8e0c77e36a2f
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWof9nAAoJEMK/C8Qzz8izJRQH/jWdMAFlN4z1ypgbInx82peB
BWzqLlIXYbMAqSu9WjCYJENyfv48R9WFkAPvndZ5tRUnRbqhvJo/6AD2IO+NAsj+
PwpQ/A/izwtEZYypI4uHZ9NA/emyh5K9MMNGsgl79S4HYt6vX0FoX8E/gjhxwgo7
3dP0Z+y7JEsEMLr7Iz/n2RR/79GMnOgTl90Oq5k/yLL7YPbwLN2kIZBOIghNbloG
hQto1POanbseEMJdNL5eBv6gQ++hzhJ6nj7d6fSYL2TQvq/FmHdB38SGvLmR/NAp
ZPkW1Vl3oc8kKNcveox85oHq8a+gOlSA5lwR5ESUoP6aJhh8Qzlp/C1S/FQ5uT8=
=FzF+
-END PGP SIGNATURE-

php-5.6.18RC1.tar.xz
SHA256 hash:
e14f1830be7c219a2ddb23c387e61166cad649dee45016d502f018cb3d64a363
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWof9tAAoJEMK/C8Qzz8izSzIIAMbLBA6xL1aVBaq4iRZOwLRo
mjoPm9G1uAiWhL8jTI2ufNaW3XO7CYhExiKjpa93WVoTOHKD7OgNnEJ5B3wP5mKJ
SLPu0bo12HcBYu83HXtahjV9FcT6Pwk6fTQ+PEcw7KE8QhWfuRjKeRWA9J47viOa
LPkxlrmyQ9cYGNWpvnxs5y0VrncMN91Jci0jG9iWf+NyiczmbLbHMOdcWIVZ66Zp
1t9tN/ga2Hm5XQ5sS6Je/R/VX2N8oo61jWW5DYRZzprDhqmJ9O3SPlvQZ8kqDa+h
QVxe4EyKf4m8vU+KWsz8FrWowM3HiNllSThwcsVcrxMFhOSc8W8XFbxPXxprEeE=
=yHdZ
-END PGP SIGNATURE-

Thank you for your support.

Ferenc Kovacs & Julien Pauli