Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71197
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXb6jLX8HMN-rL7t5j5R_0SaeRkd5r4_MrmQFfsJxxaSxQ@mail.gmail.com>
References: <CAGa2bXauxj6Sca8qYk2cxQ=TeG4bjWgcv-Aqy3cJe35ap72Yfw@mail.gmail.com>
	<CAF+90c-ZgsCczU71TJap1yeaNhKgQeoUR5oLKwwHHaoOD8z_ig@mail.gmail.com>
	<CAGa2bXb6jLX8HMN-rL7t5j5R_0SaeRkd5r4_MrmQFfsJxxaSxQ@mail.gmail.com>
Date: Thu, 16 Jan 2014 23:38:00 +0100
Message-ID: <CAF+90c-JBP5iY_DmkSq7Ao6w4rkWoFp9xdwJ9frtQGdxyLyztQ@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b33d3ceea303d04f01e13cd
Subject: Re: [PHP-DEV] [RFC] Multibyte char handling
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7b33d3ceea303d04f01e13cd
Content-Type: text/plain; charset=ISO-8859-1

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

--047d7b33d3ceea303d04f01e13cd--