[VOTE] Multbye char handling - Remove vulnerability related to multibyte short and long term

From: Date: Mon, 10 Feb 2014 03:56:49 +0000
Subject: [VOTE] Multbye char handling - Remove vulnerability related to multibyte short and long term
Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
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
[email protected]


Thread (11 messages)

« previous php.internals (#72427) next »