Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72427
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.176 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
Date: Mon, 10 Feb 2014 12:56:49 +0900
Message-ID: <CAGa2bXaq+S8hhPW4Mx1KTWjhXk=OL+J5hHWoS-t0Q-5hJOxBow@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11381264b2c61704f20556a4
Subject: [VOTE] Multbye char handling - Remove vulnerability related to
 multibyte short and long term
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11381264b2c61704f20556a4
Content-Type: text/plain; charset=UTF-8

Hi all,

Current PHP has security issue that attacker may execute arbitrarily script
via encoding based attack. These 2 RFCs are for short and long term
resolution for this issue.



Short term: Multibyte Char Handling
https://wiki.php.net/rfc/multibyte_char_handling
Add functions required to resolve security issues. CVE-2014-1239


Long term: Alternative implementation of mbstring using ICU
https://wiki.php.net/rfc/altmbstring
We need multibyte feature as default. However, current mbstring has license
issues. Resolve license issues by alternative mbstring in the future.
Introduce mbstring-ng as EXPERIMENTAL module for further development,
testing, feedback from users.

VOTE: 2014/02/10 - 2014/02/17



Please note that these RFCs are independent from whether PHP is going to
support Unicode in core or not. It's about how PHP provides required
features. Even when PHP supports UTF-8 as string encoding, these multibyte
features are required. Otherwise, encoding parameter/property is mandatory
for core multibyte support. We need to support existing applications long
term also.

Since it is security related issue, please provide/propose alternative
resolution if anyone feels it is not the way to go. There must be feasible
resolution.

Thank you for voting and/or alternative proposal!
Even though alternative is better to proposed during discussion period,
better alternative is welcomed at anytime.

Regards,

P.S. We are better to have comment field in RFC. It is not constructive
just voting "No" without reason/alternative. Alternatively, we may have rule
to post mail here explains the reason why.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11381264b2c61704f20556a4--