Re: [RFC] Multibyte char handling

On Thu, Jan 16, 2014 at 11:34 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > Hi Nikita, > > On Thu, Jan 16, 2014 at 9:18 PM, Nikita Popov <nikita.ppv@gmail.com>wrote: > >> On Thu, Jan 16, 2014 at 12:50 AM, Yasuo Ohgaki <yohgaki@ohgaki.net>wrote: >> >>> Hi all, >>> >>> addslashes() could be vulnerable via char encoding based attacks. >>> It is needed to decide what counter measure we adopt. >>> This is RFC for this issue. >>> >>> https://wiki.php.net/multibyte_char_handling >>> >>> Please comment. >>> Thank you. >>> >> >> Please do *not* add encoding parameters to our existing string functions >> - we have an mb extension and mb functionality should go there. Don't mix >> the things, it will only lead to a lot of confusion. Right now it's obvious >> which functions handle encoding how, no need to break that. >> > > This discussion circulate discussion. > > At first, I proposed locale based solution using php_mblen(). > This approach does not require additional encoding parameter > since encoding is specified by locale. > > However, some people don't like the solution (in security ML) > because it is locale based solution. It may have unwanted side > effects. Locale is unreliable and most user just don't care about it. > > Therefore, I proposed this approach that introduce encoding > parameter just like htmlspecialchars()/htmlentities(). > > Encoding parameter (or some way to specify encoding) for security > related string function is mandatory. We should provide some way > to specify encoding. > > Do you like locale based approach for now? > No, I don't want a locale-based approach. I want the string functions to stay as is. Multibyte variants of the functions can be added to the multibyte extension. Nikita