Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71664 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 75626 invoked from network); 28 Jan 2014 10:19:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Jan 2014 10:19:08 -0000 Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.113.146.227 xdebug.org Linux 2.6 Received: from [82.113.146.227] ([82.113.146.227:47300] helo=xdebug.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5F/5B-01140-91487E25 for ; Tue, 28 Jan 2014 05:19:07 -0500 Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id 4B72010D502; Tue, 28 Jan 2014 10:19:01 +0000 (GMT) Date: Tue, 28 Jan 2014 10:19:01 +0000 (GMT) X-X-Sender: derick@whisky.home.derickrethans.nl To: Yasuo Ohgaki cc: Nikita Popov , "internals@lists.php.net" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] [VOTE] RFC: Multibyte Char Handling From: derick@php.net (Derick Rethans) On Sun, 26 Jan 2014, Yasuo Ohgaki wrote: > Hi Nikita, > > On Sun, Jan 26, 2014 at 9:38 AM, Nikita Popov 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