Re: [VOTE] Multbye char handling - Remove vulnerability related tomultibyte short and long term

From: Date: Mon, 10 Feb 2014 07:25:55 +0000
Subject: Re: [VOTE] Multbye char handling - Remove vulnerability related tomultibyte short and long term
References: 1  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 
On 02/10/2014 03:56 AM, Yasuo Ohgaki wrote:

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]



I voted no, on both.

The first rfc doesn't even contain a patch, so I have nothing to review, I don't much care what you think the reasons are for the change, I care what the code says, and there isn't any.

The second RFC is based on an extension that was written 5 years ago and hasn't been touched since.

Not good enough, nothing like good enough ...

Cheers
Joe

Thread (11 messages)

« previous php.internals (#72428) next »