On Thu, Jul 30, 2015 at 8:38 AM, Craig Francis <cr...@craigfrancis.co.uk> wrote:
> 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 The RFC and bug report both make an erroneous assumption that unescaped GPC input is wrong. I was addressing some cases where it is the correct, intended, behavior. WRT "breaking": Application stacks which go from zero E_NOTICE warnings, to hundreds or thousands of them a second or day, is (admittedly) poorly phrased as "breaking". It is a possible side effect of the proposed solutiions. I have worked in very stingent environments where an unapproved E_NOTICE is considered a ship-stop break, but I did not explicitly explain that. Such environments would require re-writes of all SQL that throws an E_NOTICE, or a per-line exception review and approval process, or disabling/not enabling the checking. > 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. "Rarely" is subjective at this point, a quanyifyable sampling of some kind could be more meaningful. (How rare?) Based on *my* purely anecdotal experience, in the last X years of using PHP I have have frequently encountered situations where passing through engine-unescaped text strings, to SQL, is desired for some reason, in nearly every environment. I mentioned one use case that I thought might be relevant to a large number of users, there are others. Off the top of my head, some use cases I have dealt with relevant to this discussion, that should be considered (even if they're discarded as trivial): 1. Administrator has a web application that is supposed to allow them access functionally equivalent to a direct connection to a database. 2. Overhead of using the engine escaping technique (setup connection(if not done yet), send text to escape at network speed, recieve escaped text at network speed) was considered too much of an additional performance hit. 3. Text needed to have a generic, user written, escaping library/function to handle multiple destinations (think 5 different data storage systems, all with different escaping rules, some without connection based escaping). 4. Text being supplied was coming from a pre-cleaned, trusted, source, even though the variable was GPC, (example: it was a GET string assembled by a batch job that was pulling from another database) I'm sure there are many more. Basing language decisions on personal perceptions of "rarely" and "frequently" is not a good practice, but ensuring that we are covering multiple use-cases is. Discussing the use cases doesn't mean I think the idea is without merit. -Ronabop
