I find myself agreeing with Pierre; The wrong signal would be sent. History should teach us there is no such thing as (a) safe mode.
Xinchen did used to work on a taint extension, I wonder why that was stopped ? Worth noticing that the extension is rather complex, touching many parts of the engine, changing many things ... which I don't really like. Cheers Joe On Thu, Jul 30, 2015 at 10:14 AM, Craig Francis <cr...@craigfrancis.co.uk> wrote: > On 30 Jul 2015, at 08:24, Lester Caine <les...@lsces.co.uk> wrote: > > > But that is a perfect example of what I am talking about. You do not > > educate people by publishing the very thing that is wrong. You educate > > them by pointing out to them WHY the '?' was there in the first place. > > > > > I completely agree on education, and what I'm hoping for... and this is > how we can educate everyone :-) > > My suggestion for taints (not quite the same as the one from Matt or > Wietse) was not to change the way good programs are created/executed, but > simply an education device, which can also pick up mistakes that > experienced developers make. > > While my first post on this mailing list gives a better overview: > > http://news.php.net/php.internals/87207 > > The original implementation suggestion is at: > > https://bugs.php.net/bug.php?id=69886 > > You will see that it does nothing more than create notices to say "erm, do > you want to be doing this?". > > This is something that only PHP can do, unless you can find a way of > changing every single article / code example on the internet :-) > > So, with your example... if you want to use a variable for a table/field > prefix, that is perfectly fine... in fact, it won't need any changes, as > the prefix will probably be hard coded as a string within a PHP script > (something I called ETYPE_CONSTANT). > > But if not (e.g. storing the prefix in an ini file?), then I've shown an > example of how that can be handled with the proposed "string_encoding_set" > function (something I should have probably called string_escaping_set)... > which is simply to tell PHP that this one variable is already safe > (something I can't see being needed very often). > > Craig > > > > > > On 30 Jul 2015, at 08:24, Lester Caine <les...@lsces.co.uk> wrote: > > > On 29/07/15 16:11, Craig Francis wrote: > >> I completely disagree... prepared statements are just as vulnerable, > and so are ORM's. > >> > >> You can push developers towards these solutions, and that would be > good, but you are completely blind if you think an uneducated developer > won't do: > >> > >> if ($stmt = $mysqli->prepare("SELECT District FROM City WHERE > Name=" . $_GET['name'])) { > >> } > > > > But that is a perfect example of what I am talking about. You do not > > educate people by publishing the very thing that is wrong. You educate > > them by pointing out to them WHY the '?' was there in the first place. > > > > Since the taint extension only covers mysql and sqlite it's of little > > use if we manage to convert 'uneducated developer' to any of the more > > secure databases, and that was one of the reasons why mysql was dropped > > from being loaded by default. Once one starts from a base of > > parametrised sql queries the lax programming methods many mysql guides > > and books continue to push can be reversed. Throwing more bloat into php > > to create 'WTF' errors just adds to a new users frustration and annoys > > experienced users who have very good reasons for building queries using > > clean variables. MANY abstraction layers use variables to add prefixes > > to table names or fields. > > > > Educate ... don't nanny ... > > > > -- > > 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 Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
