On 30 Jul 2015, at 16:26, Ronald Chmara <[email protected]> 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 <[email protected]> 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.