Re: [PHP-DEV] disabling ereg
is it not emulated using pcre now? as in, the ereg library is not used anymore On Tue, Jan 10, 2012 at 8:49 AM, Philip Olson wrote: > Hi geeks! > > We're unable to disable the ereg extension today, yet it's been deprecated > since PHP 5.3.0. Is this by design? > > Regards, > Philip > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.9, Hash DoS, release
2012/1/10 Xinchen Hui > On Tue, Jan 10, 2012 at 12:57 AM, Pierre Joye > wrote: > > hi, > > > > No time for new ideas yet. We cannot afford to implement, test and > > valid new propositions and provide a fix as soon as possible (read: in > > the next days). > > > > What's the status of your patch? The max input var one, not the random > > (or derived version), can you post it in this thread again for the > > record please? > Hi, FYI > > thanks > > > > If not, we will go final with the current fix in 5.3. > > > > On Mon, Jan 9, 2012 at 5:36 PM, Xinchen Hui wrote: > >> Hi: > >> I have a new idea, which is simple and also works for > Jason/serialized etc. > >> > >> That is Restricting a max length of a buckets list in a hash table. > >> > >> If a bucket's length exceed 1024, any insertion into this bucket > >> will return failure and a warning will be generated. > >> > >> What do you think? > >> > >> Sent from my iPhone > >> > >> 在 2012-1-9，23:42，Pierre Joye 写道： > >> > >>> hi, > >>> > >>> Moving this discussion here as it makes little to non sense to discuss > >>> that any longer on security@ > >>> > >>> We are now very late behind an acceptable delay to provide a fix for > >>> the hash DoS, to say it nicely. > >>> > >>> I'd strongly suggest to release 5.3.9 (RC5 has been tested now) final > >>> this week using the max_input_vars fix, with the modification from > >>> Laruence (but with a larger limit). Laruence addition also fixes > >>> serialize or json, which are parts that need this fix as well as it is > >>> impossible to valid a string manually (length check only is not enough > >>> or cannot work in all cases). > >>> > >>> But 1st of all, the fix addition has to be applied and fully tested. > >>> But if the addition is not desired yet, then we must at least release > >>> 5.3.9 with Dmitry's fix only and we can fix json&serialize later, > >>> ideally within 2 weeks max. > >>> > >>> Cheers, > >>> -- > >>> Pierre > >>> > >>> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > > > > > > > -- > > Pierre > > > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > > > -- > 惠新宸laruence > Senior PHP Engineer > http://www.laruence.com > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Why not double hashing (http://en.wikipedia.org/wiki/Double_hashing) somelike John Crenshaw proposed ? Julien
Re: [PHP-DEV] disabling ereg
Hello Pierre, I mean that the ereg extension is deprecated, yet we cannot disable it while compiling PHP. In other words, ereg() and friends always exist in PHP, and emit E_DEPRECATED errors upon use. We should have the option of creating fatal undefined function errors… basically. Currently this exists for ereg: --with-regex[=TYPE] So I guess we want: --without-regex Even though --disable-ereg would feel more natural. Regards, Philip On Jan 10, 2012, at 12:27 AM, Pierre Joye wrote: > is it not emulated using pcre now? as in, the ereg library is not used anymore > > On Tue, Jan 10, 2012 at 8:49 AM, Philip Olson wrote: >> Hi geeks! >> >> We're unable to disable the ereg extension today, yet it's been deprecated >> since PHP 5.3.0. Is this by design? >> >> Regards, >> Philip >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: SOAP
Hi! Stas, Ilia, any objections against committing it into 5.4 and 5.3? Not for 5.4 now, we're in code freeze and this does not look like critical patch. Once 5.4.0 is out, it's OK to add for 5.4.1. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: SOAP
hi Dmitry,
I suppose you mean Johannes for 5.3.
On Tue, Jan 10, 2012 at 8:11 AM, Dmitry Stogov wrote:
> Hi Alex,
>
> Right now it's possible to use SOAP with proxy using special options in
> SoapClient constructor
> (http://www.php.net/manual/en/soapclient.soapclient.php)
>
> new SoapClient($wsdl, array('proxy_host' => 'my.proxy.com',
> 'proxy_port' => '8080',
> 'proxy_login' => '',
> 'proxy_password' => ''));
>
> But I understood, that you like to use default proxy values to avoid changes
> in third-party application. So I think the patch makes sense.
>
> Stas, Ilia, any objections against committing it into 5.4 and 5.3?
>
> Thanks. Dmitry.
>
> On 01/10/2012 12:31 AM, Alex Samorukov wrote:
>>
>> Hi Dmitry,
>>
>> I created a small enchantment for the SOAP extension, could you please
>> take a look?
>>
>> https://bugs.php.net/bug.php?id=60676
>>
>> We have some clients in proxy enabled environments and its possible to
>> force proxy usage in curl or php streams, but not in SOAP. Proposed
>> patch adds new ini settings to resolve this. Please, tell if i need to
>> change anything in it.
>>
>> Thank you.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disabling ereg
what I mean is that, as far as I remember, the deprecation is only an information via the documentation. We did not want to break BC and all that as it is now emulated through pcre. On Tue, Jan 10, 2012 at 4:46 PM, Philip Olson wrote: > Hello Pierre, > > I mean that the ereg extension is deprecated, yet we cannot disable > it while compiling PHP. In other words, ereg() and friends always > exist in PHP, and emit E_DEPRECATED errors upon use. We should have > the option of creating fatal undefined function errors… basically. > > Currently this exists for ereg: > > --with-regex[=TYPE] > > So I guess we want: > > --without-regex > > Even though --disable-ereg would feel more natural. > > Regards, > Philip > > On Jan 10, 2012, at 12:27 AM, Pierre Joye wrote: > >> is it not emulated using pcre now? as in, the ereg library is not used >> anymore >> >> On Tue, Jan 10, 2012 at 8:49 AM, Philip Olson wrote: >>> Hi geeks! >>> >>> We're unable to disable the ereg extension today, yet it's been deprecated >>> since PHP 5.3.0. Is this by design? >>> >>> Regards, >>> Philip >>> >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >> >> >> >> -- >> Pierre >> >> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disabling ereg
On Tue, Jan 10, 2012 at 6:28 PM, Pierre Joye wrote: > what I mean is that, as far as I remember, the deprecation is only an > information via the documentation. We did not want to break BC and all > that as it is now emulated through pcre. no, we deprecated it, and albeit it was a discussion to un-deprecate it, we kept it: I think we have enough reasons to keep it deprecated as we have much better alternative (pcre) which we want to recommend to the users. http://lxr.php.net/opengrok/xref/PHP_5_4/ext/ereg/ereg.c#54 -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] "Cannot use $this as lexical variable" message still in PHP 5.4
Hi Etienne: > To me it seems similar to assigning $this, only here it is via special > closure syntax. Since this code is no longer necessary, and might conflict > with the rebinding of $this, the error makes sense IMHO. A clearer error message seems appropriate. It should indicate that use($this) is inappropriate, but that $this can be used. Something _like_ "$this is available without being declared." Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disabling ereg
Can you please carefully read what I wrote? Thanks. I said: " the deprecation is only an information via the documentation" as in not adding noises to the language without any good reason. On Tue, Jan 10, 2012 at 7:11 PM, Ferenc Kovacs wrote: > > > On Tue, Jan 10, 2012 at 6:28 PM, Pierre Joye wrote: >> >> what I mean is that, as far as I remember, the deprecation is only an >> information via the documentation. We did not want to break BC and all >> that as it is now emulated through pcre. > > > no, we deprecated it, and albeit it was a discussion to un-deprecate it, we > kept it: > I think we have enough reasons to keep it deprecated as we have much better > alternative (pcre) which we want to recommend to the users. > http://lxr.php.net/opengrok/xref/PHP_5_4/ext/ereg/ereg.c#54 > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disabling ereg
Hi! This thread has veered off-course. So to summarize: (1) ereg is deprecated, and usage is discouraged (2) It emits E_DEPRECATED errors as of PHP 5.3 (3) We cannot disable/remove ereg at compile time (today) I'm suggesting we alter (3) so that we, the people who compile PHP, can optionally remove this extension from our PHP 5.4+. This means adding --without-regex to go along with --with-regex, which is the current compile-time option for ext/ereg. Any objections? Regardless of deprecation status, this option should be available. Or if not, why? Regards, Philip On Jan 10, 2012, at 10:41 AM, Pierre Joye wrote: > Can you please carefully read what I wrote? Thanks. > > I said: > > " the deprecation is only an information via the documentation" > > as in not adding noises to the language without any good reason. > > On Tue, Jan 10, 2012 at 7:11 PM, Ferenc Kovacs wrote: >> >> >> On Tue, Jan 10, 2012 at 6:28 PM, Pierre Joye wrote: >>> >>> what I mean is that, as far as I remember, the deprecation is only an >>> information via the documentation. We did not want to break BC and all >>> that as it is now emulated through pcre. >> >> >> no, we deprecated it, and albeit it was a discussion to un-deprecate it, we >> kept it: >> I think we have enough reasons to keep it deprecated as we have much better >> alternative (pcre) which we want to recommend to the users. >> http://lxr.php.net/opengrok/xref/PHP_5_4/ext/ereg/ereg.c#54 >> >> -- >> Ferenc Kovács >> @Tyr43l - http://tyrael.hu > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disabling ereg
On Tue, 2012-01-10 at 18:28 +0100, Pierre Joye wrote: > what I mean is that, as far as I remember, the deprecation is only an > information via the documentation. We did not want to break BC and all > that as it is now emulated through pcre. There is no emulation, the behavior of the ereg library and pcre is different that emulation is not possible in a useful way. It is also not only in documentation but by throwing E_DEPRECATED. > > Currently this exists for ereg: > > > > --with-regex[=TYPE] > > > > So I guess we want: > > > > --without-regex > > > > Even though --disable-ereg would feel more natural. --disable is the counterpart to --enable as generated by autoconf. --without the counterpart to --with. We use --with for things using some library. ereg uses by default a bundled library but could also be configured to use a system configured library. Therefor "--with" is correct, therefore --without is the "correct" consequence. > >>> We're unable to disable the ereg extension today, yet it's been > >>> deprecated since PHP 5.3.0. Is this by design? It's at least partly by design. We had some code using ereg library stuff internally, so core PHP depended on it. The plan was to rewrite these code parts to use pcre. I'm not sure that has been done, yet. Till then we can't make ereg optional. We should look into this for 5.5, using ereg is a bit dangerous (0-byte safety etc.) so dropping it is a good thing, even aside from reducing the amount of code to maintain. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disabling ereg
Hi! (1) ereg is deprecated, and usage is discouraged (2) It emits E_DEPRECATED errors as of PHP 5.3 (3) We cannot disable/remove ereg at compile time (today) I'm suggesting we alter (3) so that we, the people who compile PHP, can optionally remove this extension from our PHP 5.4+. OK, propose a patch :) Note that pgsql seems to be using regex, and may be other modules, so it should be made to use PCRE instead I guess. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disabling ereg
On 01/10/2012 11:33 AM, Philip Olson wrote: > Any objections? Regardless of deprecation status, this option > should be available. Or if not, why? The main reason is that we are not done removing all the dependencies. This is a large deprecation that is going to require the process to span multiple versions. We could add a way to disable it, but it is going to break some extensions in ways that are not obvious to the user. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for #54254
This is a patch to fix the main issue in bug #54254,
cal_from_jd(CAL_JEWISH) returns month=6 for Adar when there is only
one Adar, (it should return 7, since if there is only one Adar it's
AdarII). This will clear up an issue where cal_from_jd() returns a
month that cal_days_in_month() reports to have 0 days due to an
inconsistency in how dates are converted to and from the Jewish
calendar. This patch should create the correct behavior.
I hope this can be applied and put into place soon, as this bug causes
malfunctions that have to be worked around.
Thanks,
Eitan
https://bugs.php.net/bug.php?id=54254
Index: ext/calendar/tests/jdtojewish.phpt
===
--- ext/calendar/tests/jdtojewish.phpt (revision 322030)
+++ ext/calendar/tests/jdtojewish.phpt (working copy)
@@ -14,10 +14,11 @@
jdtojewish(gregoriantojd(10,8,2002),true, CAL_JEWISH_ADD_GERESHAYIM)."\r\n".
jdtojewish(gregoriantojd(10,8,2002),true, CAL_JEWISH_ADD_GERESHAYIM+CAL_JEWISH_ADD_ALAFIM_GERESH)."\r\n".
jdtojewish(gregoriantojd(10,8,2002),true, CAL_JEWISH_ADD_GERESHAYIM+CAL_JEWISH_ADD_ALAFIM)."\r\n".
- jdtojewish(gregoriantojd(10,8,2002),true, CAL_JEWISH_ADD_GERESHAYIM+CAL_JEWISH_ADD_ALAFIM+CAL_JEWISH_ADD_ALAFIM_GERESH)."\r\n");
+ jdtojewish(gregoriantojd(10,8,2002),true, CAL_JEWISH_ADD_GERESHAYIM+CAL_JEWISH_ADD_ALAFIM+CAL_JEWISH_ADD_ALAFIM_GERESH)."\r\n".
+ jdtojewish(gregoriantojd(3,10,2007))."\r\n");
?>
--EXPECT--
-string(184) "2/22/5763
+string(195) "2/22/5763
כב חשון התשסג
כב חשון ה'תשסג
כב חשון ה אלפים תשסג
@@ -27,4 +28,5 @@
ב' חשון ה'תשס"ג
ב' חשון ה אלפים תשס"ג
ב' חשון ה' אלפים תשס"ג
+7/20/5767
"
Index: ext/calendar/jewish.c
===
--- ext/calendar/jewish.c (revision 322030)
+++ ext/calendar/jewish.c (working copy)
@@ -587,11 +587,11 @@
(*pMonth)--;
(*pDay) += 30;
} else {
-*pMonth = 6;
+*pMonth = 7;
*pDay = inputDay - tishri1 + 207;
if (*pDay > 0)
return;
-(*pMonth)--;
+(*pMonth)-=2;
(*pDay) += 30;
}
if (*pDay > 0)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disabling ereg
> (3) We cannot disable/remove ereg at compile time (today) > > I'm suggesting we alter (3) so that we, the people who compile > PHP, can optionally remove this extension from our PHP 5.4+. For what it's worth, I was able to successfully remove ereg from PHP 5.3 (.6, I think; this was a while ago) by just removing ext/ereg from the source tree before running configure (same with reflection and spl). I presume though that this only worked because I happened to disable all extensions that depended on ereg at the same time. Even so, an option would be useful even if it was accompanied by a warning saying that it might break the build depending on other extension choices. -- Oleg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disabling ereg
On Jan 10, 2012, at 11:54 AM, Rasmus Lerdorf wrote: > On 01/10/2012 11:33 AM, Philip Olson wrote: >> Any objections? Regardless of deprecation status, this option >> should be available. Or if not, why? > > The main reason is that we are not done removing all the dependencies. > This is a large deprecation that is going to require the process to span > multiple versions. We could add a way to disable it, but it is going to > break some extensions in ways that are not obvious to the user. Makes sense. Removing ereg dependencies from PHP 5.5 (trunk) seems like the wise choice, and adding --without-regex then as well. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disabling ereg
We can only do it for a 6.x, not for a 5.5. So I would not do it too early in the process. On Wed, Jan 11, 2012 at 12:14 AM, Philip Olson wrote: > > On Jan 10, 2012, at 11:54 AM, Rasmus Lerdorf wrote: > >> On 01/10/2012 11:33 AM, Philip Olson wrote: >>> Any objections? Regardless of deprecation status, this option >>> should be available. Or if not, why? >> >> The main reason is that we are not done removing all the dependencies. >> This is a large deprecation that is going to require the process to span >> multiple versions. We could add a way to disable it, but it is going to >> break some extensions in ways that are not obvious to the user. > > Makes sense. Removing ereg dependencies from PHP 5.5 (trunk) seems like > the wise choice, and adding --without-regex then as well. > > Regards, > Philip > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
