Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
2014.10.17. 6:51 ezt írta (Rasmus Lerdorf ras...@lerdorf.com): On 10/16/2014 09:10 AM, Ferenc Kovacs wrote: I don't think we should remove the option, just change the defaults, and most people would be fine switching back to the emulation, but it should be their conscious decision imo. Currently many people aren't aware that they are using client side prepares, and they are pretty much ignore the fact, that they can be exposed to sql injections (for example via using mismatching client and server encodings or not properly quoting the identifiers: http://www.codeyellow.nl/identifier-sqli.html because they think that server side prepared statements would be immune to this kind of problems). I think you have the wrong idea here. That link you pointed to talks about SQLi in identifiers. Server-side prepares are just as vulnerable to this, so switching from client-side to server-side does nothing to make this safer. Server side prepares does not support parameter binding for identifiers so while you can still be vulnerable if you concatenate variables into your query, but you wouldn't think that you are immune to sql injection that way. Emulated prepares make it look like that you are. As far as a charset mismatch between the client and the server when it comes to preparing query values, PDO's implementation handles that. You need a connection handle to do a prepare so we know the charset and take that into account. Same thing here, while (since 5.3.6 afair) you are able to pass the encoding information to the pdo driver (before that you could only use set names which pdo doesn't care about) the emulation still make it look like that you are immune, because many people aren't aware of the emulation and assumes that they are immune to sqli because the params travel as separate entity from the query to the server.
[PHP-DEV] PHP 5.5.18 is available
Hello! The PHP development team announces the immediate availability of PHP 5.5.18. Four security-related bugs were fixed in this release, including fixes for CVE-2014-3668, CVE-2014-3669 and CVE-2014-3670. PHP 5.5.18 also fixes a regression that was unfortunately included into PHP 5.5.17, regarding SSL Streams. All PHP 5.5 users are encouraged to upgrade to this version. For source downloads of PHP 5.5.18 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The full list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.5.18 Julien Pauli David Soria Parra
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
On 16/10/14 18:59, christopher jones wrote: The MySQL team has been improving their server-side prepare code: http://mysqlserverteam.com/re-factoring-some-internals-of-prepared-statements-in-5-7/ It may be worth clarifying some terms here since people are talking about restrictions that MySQL creates for itself and which are not normal limitations in other engines. This article identifies the simple fact that MySQL is still playing catchup when it comes to PARAMETRIZED statements. Something which is the norm in other engines. One of the best ways of maintaining security against SQLi IS to pass data as parameters and so anybody trying to be clever by replacing a text value by SQL fails at the first hurdle. Once using parameters then prepare is a required step anyway. It is not optional. It's facets like this which are one of the reasons that PDO is NOT a good base to build on top of as it assumes the lowest common denominator is the norm? Which it has to. Ulf stated early on in this thread re MySQL - statement and parameter are send to the server independently - the server builds the final statement string Is this ACTUALLY how it works? Since other engines prepare the statement and bind buckets to put the parameters in. They never 'build the final statement string' and there is no 'client side prepare' because the concept can't exist. Some other engines may support named parameters via client side juggling, but that just hides the underlying fixed order requirements it does not replace the bind process. PDO has a number of restrictions which prevent facilities available on other engines from being used. Is this just another area where the attempts to make every one seem the same is actually more of a hindrance than a help? Passing a fully assembled SQL statement over the wire should always be a last resort rather than the norm once it's content is provided via external routes. I don't need to call 'prepare' in Firebird, it will be handled as required so having that step carried out by the client side is the waste of traffic. The next version of Firebird will actually start caching prepared statements on persistent connections which I'm just waiting to play with! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
Am 17.10.2014 um 11:51 schrieb Lester Caine: On 16/10/14 18:59, christopher jones wrote: Ulf stated early on in this thread re MySQL - statement and parameter are send to the server independently - the server builds the final statement string Is this ACTUALLY how it works? Since other engines prepare the statement I thought this was a mailing list about PHP. I even believed from the headline the question would be whether PHP users of MySQL would like to change an API default setting. But no, its about explaining the MySQL source code to Firebird lovers. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fwd: [PHP-CVS] com php-src: Don't make difference between undefined and unaccessible properies when call __get() and family: Zend/zend_object_handlers.c
Please think if it may break something.
I wasn't able to find out a case.
Thanks. Dmitry.
-- Forwarded message --
From: Dmitry Stogov dmi...@php.net
Date: Fri, Oct 17, 2014 at 3:01 PM
Subject: [PHP-CVS] com php-src: Don't make difference between undefined and
unaccessible properies when call __get() and family:
Zend/zend_object_handlers.c
To: php-...@lists.php.net
Commit:f2fa7a41cfc9854e74148e6f6330181f42372371
Author:Dmitry Stogov dmi...@zend.com Fri, 17 Oct 2014
15:01:54 +0400
Parents: 6b203aa26243a46775483a1318427b081095c126
Branches: master
Link:
http://git.php.net/?p=php-src.git;a=commitdiff;h=f2fa7a41cfc9854e74148e6f6330181f42372371
Log:
Don't make difference between undefined and unaccessible properies when
call __get() and family
Changed paths:
M Zend/zend_object_handlers.c
Diff:
diff --git a/Zend/zend_object_handlers.c b/Zend/zend_object_handlers.c
index d143b00..ba08967 100644
--- a/Zend/zend_object_handlers.c
+++ b/Zend/zend_object_handlers.c
@@ -423,41 +423,19 @@ ZEND_API int zend_check_property_access(zend_object
*zobj, zend_string *prop_inf
}
/* }}} */
-static zend_long *zend_get_property_guard(zend_object *zobj,
zend_property_info *property_info, zval *member) /* {{{ */
+static zend_long *zend_get_property_guard(zend_object *zobj, zval *member)
/* {{{ */
{
- zend_property_info info;
zval stub, *guard;
- zend_string *str = NULL;
- if (!property_info) {
- property_info = info;
- info.name = Z_STR_P(member);
- } else if(property_info-name-val[0] == '\0'){
- const char *class_name = NULL, *prop_name = NULL;
- size_t prop_name_len;
- zend_unmangle_property_name_ex(property_info-name,
class_name,
- prop_name, prop_name_len);
- if (class_name) {
- /* use unmangled name for protected properties */
- str = info.name = zend_string_init(prop_name,
prop_name_len, 0);
- property_info = info;
- }
- }
if (!zobj-guards) {
ALLOC_HASHTABLE(zobj-guards);
zend_hash_init(zobj-guards, 8, NULL, NULL, 0);
- } else if ((guard = zend_hash_find(zobj-guards,
property_info-name)) != NULL) {
- if (str) {
- zend_string_release(str);
- }
+ } else if ((guard = zend_hash_find(zobj-guards, Z_STR_P(member)))
!= NULL) {
return Z_LVAL_P(guard);
}
ZVAL_LONG(stub, 0);
- guard = zend_hash_add_new(zobj-guards, property_info-name, stub);
- if (str) {
- zend_string_release(str);
- }
+ guard = zend_hash_add_new(zobj-guards, Z_STR_P(member), stub);
return Z_LVAL_P(guard);
}
/* }}} */
@@ -500,7 +478,7 @@ zval *zend_std_read_property(zval *object, zval
*member, int type, void **cache_
/* magic get */
if (zobj-ce-__get) {
- zend_long *guard = zend_get_property_guard(zobj,
property_info, member);
+ zend_long *guard = zend_get_property_guard(zobj, member);
if (!((*guard) IN_GET)) {
zval tmp_object;
@@ -633,7 +611,7 @@ found:
/* magic set */
if (zobj-ce-__set) {
- zend_long *guard = zend_get_property_guard(zobj,
property_info, member);
+ zend_long *guard = zend_get_property_guard(zobj, member);
if (!((*guard) IN_SET)) {
zval tmp_object;
@@ -807,7 +785,7 @@ static zval *zend_std_get_property_ptr_ptr(zval
*object, zval *member, int type,
}
if (!zobj-ce-__get ||
- (guard = zend_get_property_guard(zobj, property_info,
member)) == NULL ||
+ (guard = zend_get_property_guard(zobj, member)) == NULL ||
(property_info ((*guard) IN_GET))) {
ZVAL_NULL(tmp);
@@ -873,7 +851,7 @@ static void zend_std_unset_property(zval *object, zval
*member, void **cache_slo
/* magic unset */
if (zobj-ce-__unset) {
- zend_long *guard = zend_get_property_guard(zobj,
property_info, member);
+ zend_long *guard = zend_get_property_guard(zobj, member);
if (!((*guard) IN_UNSET)) {
zval tmp_object;
@@ -1481,7 +1459,7 @@ found:
result = 0;
if ((has_set_exists != 2) zobj-ce-__isset) {
- zend_long *guard = zend_get_property_guard(zobj,
property_info, member);
+ zend_long *guard = zend_get_property_guard(zobj, member);
if (!((*guard) IN_ISSET)) {
zval rv;
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
On 17/10/14 11:17, Ulf Wendel wrote: Am 17.10.2014 um 11:51 schrieb Lester Caine: On 16/10/14 18:59, christopher jones wrote: Ulf stated early on in this thread re MySQL - statement and parameter are send to the server independently - the server builds the final statement string Is this ACTUALLY how it works? Since other engines prepare the statement I thought this was a mailing list about PHP. I even believed from the headline the question would be whether PHP users of MySQL would like to change an API default setting. But no, its about explaining the MySQL source code to Firebird lovers. Since it is the object of PDO to create a level playing field then just how each engine handles the process is what is important so that PHP users know what they are getting and where the real security holes are. ATTR_EMULATE_PREPARES may well be a potential security hole and having to live with sites that have adopted PDO_Mysql I'd like to understand just what the process between PDO and MySQL is so I know if I have to worry or not. Yes it may affect if I take the time to switch those sites from MySQL, and maintaining them is complicated by the level of 'attack' instigated trying to find the weaknesses, so if you switch this off do I need simply to switch it back on, or take other action. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
Am 17.10.2014 um 13:47 schrieb Lester Caine: users know what they are getting and where the real security holes are. Hmm, maybe, you could make this world a better one by contributing to improve http://php.net/manual/en/pdo.prepared-statements.php ? For the rest: the MySQL manual and the MySQL source code have the details. No need for speculation towards the implementation of server-side PS in MySQL, no need playing my DB vs. your DB, no need for playing the users have a right card. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ANNOUNCE] PHP 5.4.34 Released
REMOVE FROM LISTS, PLEASE. 2014-10-17 1:51 GMT-03:00 Stas Malyshev smalys...@gmail.com: Hello! The PHP development team announces the immediate availability of PHP 5.4.34. 6 security-related bugs were fixed in this release, including fixes for CVE-2014-3668, CVE-2014-3669 and CVE-2014-3670. Also, a fix for OpenSSL which produced regressions was reverted. All PHP 5.4 users are encouraged to upgrade to this version. For source downloads of PHP 5.4.34 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.4.34 Stanislav Malyshev PHP 5.4 RM -- PHP Announcements Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
On 17/10/14 13:20, Ulf Wendel wrote: users know what they are getting and where the real security holes are. Hmm, maybe, you could make this world a better one by contributing to improve http://php.net/manual/en/pdo.prepared-statements.php ? PDO does not support management of SQL differences between databases. This page is a good example of where users run into problems because they have no idea if what they are copying actually works on their particular database. Does MySQL need ATTR_EMULATE_PREPARES in order to convert client side the SQL that it feeds over to the server? If I am converting from one database to another just what is actually supported and how? I don't use PDO with Firebird if I can help it but I am having to work with this where mysql hosting is the norm and PDO_mysql is an alternative that gets provided instead of mysqli. *I* have trouble sorting this stuff out so how do users who currently have working sites cope when things under the hood change perhaps without them even knowing. I can quite happily add notes as to what Firebird does with the various abstractions on that page, but what about every other PDO driver. Which emulate aspects of the prepares and which do it natively? Just what does get emulated? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Idea to php: client-speed, on server
Hi I've got an idea for php, but I'm not used to being out in the development environment for PHP / Apache I am a web developer in a full-time, but taught at the IT University of Copenhagen in the evening. And we are a small group of three who has been following idea, which we will work for 3 months, we will examine whether users and advertisers will be able to get something out of this. At the same time we would like to inquire us about others can see the idea. _Ide__,background__:_ A user on the mobile phone which is on a heavy website, during transport (bus, train) find that load up the sides alternately goes very fast or very slow depending on whether it is EDGE 4G coverage. The user will probably leave the page if load time available is more than 4 seconds. Typical Web pages visited during transport news providers and web commerce, which typically makes use of advertisers and web TV. The paradox is that the user on his mobile may have Internet speeds higher than typical fixed-lines, but also speeds are incredible much slower. So one can not merely the device is, whether the rate is high or low. (Eg. Via: https://code.google.com/p/php-mobile-detect/). So to distinguish between a mobile phone and a computer does not solve this. _ __Idea:_ The idea is that you can get the speed before the page header is set, and thus create either a full page or a lightweight hand. At very low speeds could be replaced images of text / color (with option-click), and at high speed could also be on the phone appears animated photos gallery, streaming commercials, etc.. In php you could have a variable, for example: $ _SERVER ['CLIENT_SPEED']. In practice, probably weighted values , for example the mean of ployed in the last 300 seconds to user does not experience the sharp up / down . Php should then get the value from Apache server ...? *_We would be grateful_* Can anybody follow our idea? We, as a group mighty like a response to this. If anyone has some general ideas for possible solution, it would be funand helpfull, but our current project, however, only reveal whether the idea is workable. If you know other people who would be more obvious to submit it to, we would be grateful to you forwarded or disclosed to who it could be. with best regards Uve Vesterbrandt Dyssevænget 65 2700 Brønshøj Danmark e-mail: u...@vesterbrandt.dk
Re: [PHP-DEV] Idea to php: client-speed, on server
On Oct 17, 2014, at 05:21, Uve Vesterbrandt u...@vesterbrandt.dk wrote: *_We would be grateful_* Can anybody follow our idea? We, as a group mighty like a response to this. If anyone has some general ideas for possible solution, it would be funand helpfull, but our current project, however, only reveal whether the idea is workable. If you know other people who would be more obvious to submit it to, we would be grateful to you forwarded or disclosed to who it could be. This isn't really feasible, and even if it was, PHP would have nothing to do with it. If the web server was able to determine the client speed and set a server variable then PHP without any modifications would provide it via $_SERVER['CLIENT_SPEED']. But there is no way the web server can determine this on its own. The only way for this to be feasible would be if the mobile browsers were to send the current connection speed as part of their USER_AGENT header or in some different header. So you should be asking Apple and Google, not us. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Idea to php: client-speed, on server
On Fri, Oct 17, 2014 at 9:26 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On Oct 17, 2014, at 05:21, Uve Vesterbrandt u...@vesterbrandt.dk wrote: *_We would be grateful_* Can anybody follow our idea? We, as a group mighty like a response to this. If anyone has some general ideas for possible solution, it would be funand helpfull, but our current project, however, only reveal whether the idea is workable. If you know other people who would be more obvious to submit it to, we would be grateful to you forwarded or disclosed to who it could be. This isn't really feasible, and even if it was, PHP would have nothing to do with it. If the web server was able to determine the client speed and set a server variable then PHP without any modifications would provide it via $_SERVER['CLIENT_SPEED']. But there is no way the web server can determine this on its own. The only way for this to be feasible would be if the mobile browsers were to send the current connection speed as part of their USER_AGENT header or in some different header. So you should be asking Apple and Google, not us. Agreed with Rasmus. This doesn't belong *in* PHP. But, as long as you can detect the speed, it would be easy to set an environment variable for or develop a framework for apps to take it into account. Likewise, the following sounds remarkably familiar to what you're talking about; hopefully it helps: http://www.quirksmode.org/blog/archives/2012/10/measuring_conne.html -- Jonah H. Harris Blog: http://www.oracle-internals.com/
Re: [PHP-DEV] Re: [ANNOUNCE] PHP 5.4.34 Released
YEAH ME TOO. On 17 Oct 2014, at 15:03, Bola Jones bolajo...@gmail.com wrote: REMOVE FROM LISTS, PLEASE. 2014-10-17 1:51 GMT-03:00 Stas Malyshev smalys...@gmail.com: Hello! The PHP development team announces the immediate availability of PHP 5.4.34. 6 security-related bugs were fixed in this release, including fixes for CVE-2014-3668, CVE-2014-3669 and CVE-2014-3670. Also, a fix for OpenSSL which produced regressions was reverted. All PHP 5.4 users are encouraged to upgrade to this version. For source downloads of PHP 5.4.34 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.4.34 Stanislav Malyshev PHP 5.4 RM -- PHP Announcements Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ANNOUNCE] PHP 5.4.34 Released
On 17 October 2014 15:36, Daniel Zulla daniel.zu...@gmail.com wrote: YEAH ME TOO. On 17 Oct 2014, at 15:03, Bola Jones bolajo...@gmail.com wrote: REMOVE FROM LISTS, PLEASE. PLEASE VISIT http://www.php.net/unsub.php AND FOLLOW THE INSTRUCTIONS THERE, AS IT STATES IN THE FOOTER OF EVERY EMAIL YOU RECEIVE FROM THE LISTS. LIKE THIS: -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php ALSO, THERE'S NO NEED TO SHOUT, WE CAN STILL HEAR YOU JUST FINE IF YOU turn caps-lock off... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ANNOUNCE] PHP 5.4.34 Released
HAVE YOU TWO CONSIDERED HTTP://WWW.PHP.NET/unsub.php? On 17 Oct 2014, at 15:36, Daniel Zulla daniel.zu...@gmail.com wrote: YEAH ME TOO. On 17 Oct 2014, at 15:03, Bola Jones bolajo...@gmail.com wrote: REMOVE FROM LISTS, PLEASE. 2014-10-17 1:51 GMT-03:00 Stas Malyshev smalys...@gmail.com: Hello! The PHP development team announces the immediate availability of PHP 5.4.34. 6 security-related bugs were fixed in this release, including fixes for CVE-2014-3668, CVE-2014-3669 and CVE-2014-3670. Also, a fix for OpenSSL which produced regressions was reverted. All PHP 5.4 users are encouraged to upgrade to this version. For source downloads of PHP 5.4.34 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.4.34 Stanislav Malyshev PHP 5.4 RM -- PHP Announcements Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ANNOUNCE] PHP 5.4.34 Released
I tried. It is not working. 2014-10-17 11:45 GMT-03:00 Andrea Faulds a...@ajf.me: HAVE YOU TWO CONSIDERED HTTP://WWW.PHP.NET/unsub.php? On 17 Oct 2014, at 15:36, Daniel Zulla daniel.zu...@gmail.com wrote: YEAH ME TOO. On 17 Oct 2014, at 15:03, Bola Jones bolajo...@gmail.com wrote: REMOVE FROM LISTS, PLEASE. 2014-10-17 1:51 GMT-03:00 Stas Malyshev smalys...@gmail.com: Hello! The PHP development team announces the immediate availability of PHP 5.4.34. 6 security-related bugs were fixed in this release, including fixes for CVE-2014-3668, CVE-2014-3669 and CVE-2014-3670. Also, a fix for OpenSSL which produced regressions was reverted. All PHP 5.4 users are encouraged to upgrade to this version. For source downloads of PHP 5.4.34 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.4.34 Stanislav Malyshev PHP 5.4 RM -- PHP Announcements Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Andrea Faulds http://ajf.me/
Re: [PHP-DEV] Re: [ANNOUNCE] PHP 5.4.34 Released
DOESN’T WORK. On 17 Oct 2014, at 16:45, Andrea Faulds a...@ajf.me wrote: HAVE YOU TWO CONSIDERED HTTP://WWW.PHP.NET/unsub.php? On 17 Oct 2014, at 15:36, Daniel Zulla daniel.zu...@gmail.com wrote: YEAH ME TOO. On 17 Oct 2014, at 15:03, Bola Jones bolajo...@gmail.com wrote: REMOVE FROM LISTS, PLEASE. 2014-10-17 1:51 GMT-03:00 Stas Malyshev smalys...@gmail.com: Hello! The PHP development team announces the immediate availability of PHP 5.4.34. 6 security-related bugs were fixed in this release, including fixes for CVE-2014-3668, CVE-2014-3669 and CVE-2014-3670. Also, a fix for OpenSSL which produced regressions was reverted. All PHP 5.4 users are encouraged to upgrade to this version. For source downloads of PHP 5.4.34 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.4.34 Stanislav Malyshev PHP 5.4 RM -- PHP Announcements Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
Am 17.10.2014 um 15:09 schrieb Lester Caine: On 17/10/14 13:20, Ulf Wendel wrote: users know what they are getting and where the real security holes are. Hmm, maybe, you could make this world a better one by contributing to improve http://php.net/manual/en/pdo.prepared-statements.php ? PDO does not support management of SQL differences between databases. This page is a good example of where users run into problems because they have no idea if what they are copying actually works on their To me, you are making noise on the wrong list and the wrong discussion thread: file a documentation bug report. Wait, I did that for you: https://bugs.php.net/bug.php?id=68254 . Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ANNOUNCE] PHP 5.4.34 Released
On 17 October 2014 15:50, Bola Jones bolajo...@gmail.com wrote: I tried. It is not working. In that case, you are probably trying to unsubscribe the wrong address, especially as I note you both use gmail, Google will deliver many variations of your address to your inbox, but the mailing list platform doesn't know this (for example, old @googlemail.com addresses will still be delivered to the new-style gmail inboxes). Check the message headers in the original message from the list (NOT these replies, as these are responding to your current sender address) and verify which address the list is sending the messages to, and try removing these messages. If you are still having problems after this, see the Still need help? section at the bottom of unsub.php to talk to a real person who can help (but remember that none of those real people are actually paid to do this, so it might take a little while to get a response). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] question regarding #67309
On Tue, Jun 3, 2014 at 2:46 PM, Andrey Andreev n...@devilix.net wrote: Hi, On Tue, Jun 3, 2014 at 3:30 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Jun 3, 2014 at 1:01 PM, Andrey Andreev n...@devilix.net wrote: On Tue, Jun 3, 2014 at 10:41 AM, Ferenc Kovacs tyr...@gmail.com wrote: Hi, I wanted to ask what's our current consensus about feature requests like this: https://bugs.php.net/bug.php?id=67309 The requested function wouldn't provide anything which isn't currently available via ini_get(), but it would be a bit natural to expect a get method where a set exists. -- Ferenc Kovács @Tyr43l - http://tyrael.hu Hi, We talked about this with Yasuo in regards to some ext/session stuff (although it was about setters) and agreed on keeping ini_set() only. He even wrote a quick RFC about it: https://wiki.php.net/rfc/deprecate-ini-functions Yeah, but AFAIR we didn't come up with an agreement (other than reverting out a couple of new functions from PHP 5.6.0). We didn't indeed, I was just giving you partial feedback. :) My opinion in general is that we don't need functions that duplicate ini_set(), ini_get() for a particular setting and existing ones should be removed in the future instead of adding more to complement them. No idea what other people think about it though. I agree that providing multiple ways to achive the same thing is not really useful. But we also have to decide whether or not it is worth the BC to remove some existing function only because one can already do the same thing via ini_set. With work supposedly being started on PHP6, now is the right time to make that decision. :) Another (albeit maybe a bit far-fetched) aspect is that somebody could assume that he/she can restrict a setting via disabling the appropriate function(via disable_functions) while that can be bypassed through the ini_set or vica versa. So the more ways we provide for the same setting to be set it is more likely that somebody forgets protecting one of those. Exactly. Cheers, Andrey. resurrecting this thread in the hope of getting a bit more feedback. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Re: [ANNOUNCE] PHP 5.4.34 Released
Ok. Thanks a lot. I´ll try again. Best Regards 2014-10-17 12:04 GMT-03:00 Chris Wright c...@daverandom.com: On 17 October 2014 15:50, Bola Jones bolajo...@gmail.com wrote: I tried. It is not working. In that case, you are probably trying to unsubscribe the wrong address, especially as I note you both use gmail, Google will deliver many variations of your address to your inbox, but the mailing list platform doesn't know this (for example, old @googlemail.com addresses will still be delivered to the new-style gmail inboxes). Check the message headers in the original message from the list (NOT these replies, as these are responding to your current sender address) and verify which address the list is sending the messages to, and try removing these messages. If you are still having problems after this, see the Still need help? section at the bottom of unsub.php to talk to a real person who can help (but remember that none of those real people are actually paid to do this, so it might take a little while to get a response).
Re: [PHP-DEV] [RFC] Big Integer Support
On 10 Oct 2014, at 22:33, Andrea Faulds a...@ajf.me wrote: The RFC can be found here: https://wiki.php.net/rfc/bigint The patch is, as I mentioned, incomplete. Additionally, there are quite a few matters left to be decided (see Open Questions). However, I think I should put this formally under discussion now. I promise not to mail the list for every change I make to this RFC. ;) But I do have quite a big one to announce. Previously, some issues with the GNU Multiple Precision Arithmetic Library (GMP) had been discovered. In particular, it is not liberally licensed (LGPL), it only has one set of custom allocators, which causes segfaults from other libraries which use it because PHP defines its own allocators, and it immediately calls an un-hookable abort() in certain failure cases. I was unaware of any good alternatives, however today I was pointed by Chris Wright (DaveRandom) on StackOverflow towards a new possibility: LibTomMath. It is liberally licensed (dual-licensed as Public Domain and WTFPL), written in pure C, packaged for multiple platforms, and it lacks the immediate abort() problem to the best of my knowledge. Plus, it will not cause any segfaults when we use custom allocators, as I do not believe PHP uses any libraries which use LibTomMath at present. If you’re worried about whether it’s battle-tested, it’s used by another dynamic language, Tcl. Because it appears to solve all three major issues with GMP, I am currently porting my bigint branch to use it. This is possible because the entire implementation of bigints is abstracted, meaning you can swap out back-ends. If we wished to, we could quite simply allow the choice of GMP at compile-time, or indeed any other back-end. I should note that LibTomMath certainly isn’t perfect. I don’t believe it is optimised to the same degree GMP is. That being said, again, it does seem to solve all the major problems I had with GMP. So I have few qualms in making the patch use it, especially given that it is easy to swap out the back-end. I’ve updated the RFC to reflect this new state of affairs: https://wiki.php.net/rfc/bigint Thoughts? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: hellosys
VCS Account Rejected: hellosys rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: covibe
VCS Account Rejected: covibe rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
