Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70675
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.213.173 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <CAGa2bXbGdC-6hcdEdQmzUn8xVKLa5Ro9NyGyFkhuMueoXuoing@mail.gmail.com>
References: <CAGa2bXbjh7EyzRf_uahHp0rfs21efqReHZKQchvB8CGjNc_Qaw@mail.gmail.com>
 <CAGa2bXbGdC-6hcdEdQmzUn8xVKLa5Ro9NyGyFkhuMueoXuoing@mail.gmail.com>
Date: Mon, 16 Dec 2013 12:54:30 -0800
Message-ID: <CADajX4DxvtZ3+fX5f6ndHOGmGs+ZAgSPFkRHVOqUwO9y5y1ZZg@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: Making addslashes() multibyte aware
From: aharvey@php.net (Adam Harvey)

On 16 December 2013 12:44, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> I don't think locale based MBCS support is optimum, but I'll add it to
> addslashes() for now.

I don't think basing behaviour on the locale is a great idea (as
evidenced by the various issues with Turkish and Azeri over the
years). Could we just add an explicit encoding parameter like
htmlspecialchars()?

> Question is where should I start?
> It's security issue for certain char encodings such as SJIS/BIG5.

Is there a case other than database access (where we've been directing
users to better APIs like PDO and mysqli for several years, at least)
where this is likely to cause security issues?

> I'll fix php_addslashes(). Therefore, any functions that use it internally
> are affected. e.g. var_export(), etc. Users are not affected as long as
> they are using correct locale.
>
> Should I fix this from 5.3?

This feels like it has the potential to be a really nasty implicit BC
break. I don't think we'd want to change default behaviour on any
stable branch, honestly.

Adam