On 16 October 2014 18:39:57 GMT+01:00, Olivier Bonvalet <php-dev.l...@daevel.net> wrote: >Le jeudi 16 octobre 2014 à 18:10 +0200, Ferenc Kovacs a écrit : >> On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf <ras...@lerdorf.com> >wrote: >> >> > On 10/16/2014 04:27 AM, Ferenc Kovacs wrote: >> > > On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara ><ircmax...@gmail.com> >> > > wrote: >> > > >> > >> Hello all, >> > >> >> > >> I raised this topic on list over a year ago ( >> > >> http://marc.info/?l=php-internals&m=130417646507744&w=2 ). It >was >> > >> determined that it wasn't time yet to disable prepared statement >> > >> emulation for MySQL yet. However, Rasmus did mention that it was >a >> > >> possibility for 5.4 ( >> > >> http://marc.info/?l=php-internals&m=130418875017027&w=2 ). Since >that >> > >> ship has sailed, I submitted a pull request for trunk to change >the >> > >> default value of prepared statement emulation for MySQL. >> > >> >> > >> https://github.com/php/php-src/pull/108 >> > >> >> > >> https://bugs.php.net/bug.php?id=54638 >> > >> >> > >> Does this need to be an RFC (should I draft one)? Or can it just >be >> > >> pulled as-is? >> > >> >> > >> Thanks, >> > >> >> > >> Anthony >> > >> >> > >> -- >> > >> PHP Internals - PHP Runtime Development Mailing List >> > >> To unsubscribe, visit: http://www.php.net/unsub.php >> > >> >> > >> >> > > hi, >> > > >> > > do we want to change the default for this in PHP7? >> > >> > Honestly, I am not sure about this anymore. There is a significant >> > performance benefit in doing client-side prepares. Last year I >attempted >> > to switch to server-side prepares on Etsy's production servers but >it >> > added 30-40ms of page latency because of the extra round trips. And >yes, >> > we were doing too many queries, but I fear if we change this >default >> > people won't understand where this slowdown is coming from. >> > >> > Of course, in some rare cases using server-side prepares might >speed >> > things up because of prepared statement caching in the server, but >I >> > have yet to see a case where that caching outweighs the extra tcp >> > roundtrip overhead. >> > >> > I do agree that the default should probably be server-side since it >is >> > the least surprising. We just need to make it very very clear in >the >> > upgrade doc that this change will likely slow down peoples' apps >and >> > show them how to turn client-side prepares back on. >> > >> > -Rasmus >> > >> >> 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 it would be better to change the default in a major version, >if the >> tradeoff is performance vs security, and if they think that they are >okay >> with the emulation, they can change it back. >> >> >> ps: >> don't forget that some/many of our users are still using php on a >single >> server setup, where the mysql connection is done through a unix >socket >> instead of the network stack, so the roundtrip there will be even >less >> noticable, and usually those are the kind of users, who need safe >defaults >> because they can't afford to be aware or change settings/code for >their >> apps. >> > >Hi, > >for me there is two usage of prepared statements : >#1 : safely handle variables >#2 : performance in batch traitments > >The first one want emulated prepared statments and the second need true >prepared.
Surely this is the other way around? Emulation has imperfect security, because it is basically a smarter version of "magic quotes", e.g. the character encoding mismatch already mentioned. It's only advantage over real prepares is performance, if network latency is a significant factor. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
