On 30 Jul 2015, at 16:26, Ronald Chmara <rona...@gmail.com> wrote: > Perhaps I have missed something in this discussion
I think you have... my email from a couple of weeks ago was ignored... so I replied to Matt's suggestion (which is similar, but different). Please, just spend a few minutes reading my suggestion, it has absolutely nothing todo with breaking applications: http://news.php.net/php.internals/87207 https://bugs.php.net/bug.php?id=69886 And yes, I do have a bypass_the_nerfing function (well, a function to say the variable has already been escaped)... but the idea is that it's ever so slightly harder to use than the related escaping functions, and rarely needed. On 30 Jul 2015, at 16:26, Ronald Chmara <rona...@gmail.com> wrote: > Perhaps I have missed something in this discussion where such a change to PHP > does not break every single application that is supposed to pass raw, user > submitted, SQL *without* getting prepared/nerfed, or warned about, by > intentional application design. > > If we're just limiting the nerfing for submitted GPC variables (since PHP is > used a lot for web applications).... we still have a non-trivial number of > those installed applications which require raw, user created, unescaped SQL, > passing through to function as designed. > > I am thinking of the class of applications like phpMyAdmin, as well as the > the millions of other database utility scripts, application install scripts, > (etc.) out there that perform similar tasks, that need to pass raw SQL, as > crafted by users, without preparation, intentionally. > > Of course, we could just add a "bypass_the_nerfing()" function, and such a > function could then possibly see widespread adoption, everywhere, rendering > the entire exercise moot. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
