Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72428
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 74.125.82.47 cause and error)
Message-ID: <52F87F03.1080100@pthreads.org>
Date: Mon, 10 Feb 2014 07:25:55 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>, 
 PHP internals <internals@lists.php.net>
References: <CAGa2bXaq+S8hhPW4Mx1KTWjhXk=OL+J5hHWoS-t0Q-5hJOxBow@mail.gmail.com>
In-Reply-To: <CAGa2bXaq+S8hhPW4Mx1KTWjhXk=OL+J5hHWoS-t0Q-5hJOxBow@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [VOTE] Multbye char handling - Remove vulnerability related tomultibyte
 short and long term
From: pthreads@pthreads.org (Joe Watkins)

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
> yohgaki@ohgaki.net
>

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