Re: [VOTE] RFC: Multibyte Char Handling

From: Date: Tue, 28 Jan 2014 10:19:01 +0000
Subject: Re: [VOTE] RFC: Multibyte Char Handling
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Sun, 26 Jan 2014, Yasuo Ohgaki wrote:

> Hi Nikita,
> 
> On Sun, Jan 26, 2014 at 9:38 AM, Nikita Popov <[email protected]> wrote:
> 
> > This RFC conflates the addition of a multibyte version of addslashes (in
> > response to quoted CVE) with the replacement of the mbstring extension by a
> > completely different implementation (and an incomplete one at that). Those
> > two things have very little to do with each other and should not be covered
> > in the same RFC and/or vote.
> 
> The root cause of this issue is lack of multibyte aware functions that 
> relates to security.

Yes, and the only way to address that properly is to make PHP support 
Unicode. This proposal adds layers of hacks to go around it - and 
although there is a possibility for broken data, I don't think it's 
worth doing.

> I've wrote the RFC to compile current mbstring by default at first, 
> but it was withdrawn. The reason why is that mbstring is using LGPLed 
> libraries. As long as it is loaded as shared module, there would not 
> be issue. However, if these are compiled and used statically, LGPL 
> will be effective.
> 
> To avoid this issue, mbstring would be better to replaced by mbstring-ng
> and move mbstring to PECL for future release.
> 
> I'll work on mbstring-ng so that it has all mbstring features. Until then,
> we may have it as EXPERIMENTAL.

We already have intl - why add another mbstring like function thing?

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine


Thread (20 messages)

« previous php.internals (#71664) next »