Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72702
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAGa2bXbNeUr73k5A6FnSevJb4GNrEk8r1om8geDLqv6gG93TVQ@mail.gmail.com>
References: <CAGa2bXaq+S8hhPW4Mx1KTWjhXk=OL+J5hHWoS-t0Q-5hJOxBow@mail.gmail.com>
 <CAGa2bXbNeUr73k5A6FnSevJb4GNrEk8r1om8geDLqv6gG93TVQ@mail.gmail.com>
Date: Thu, 20 Feb 2014 19:55:13 +0900
Message-ID: <CAGa2bXbZnUUD4AuhUzV_koQou8-S6b+Vk3D+TCMfy2W8d+Ae-g@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0160c2be5ffc5404f2d459da
Subject: Re: [VOTE] Multbye char handling - Remove vulnerability related to
 multibyte short and long term
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e0160c2be5ffc5404f2d459da
Content-Type: text/plain; charset=UTF-8

Hi all,

On Thu, Feb 20, 2014 at 7:43 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> On Mon, Feb 10, 2014 at 12:56 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>>
>> Short term: Multibyte Char Handling
>> https://wiki.php.net/rfc/multibyte_char_handling
>> Add functions required to resolve security issues. CVE-2014-1239
>>
>
> https://wiki.php.net/rfc/multibyte_char_handling#vote
>
> Vote is declined 2 vs 10.
>
>
>>
>> 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 is declined 1 vs 10.
>
> Thank you for voting all!
>
> I do not care much about long term solution, but short term solution.
>
> It seems there is a misunderstanding how vulnerabilities should be
> evaluated by developers. If one is developer of a product, vulnerability
> should be evaluated only by *consequence*, not the probability, number of
> affected users, etc.
>
> One should not evaluate his/her product's vulnerability as an user. If
> user is not affected, any vulnerabilities are not important even if it is a
> vulnerability that executes arbitrarily codes. This is a bug that may allow
> attackers to execute their code. Consequence is fatal. I hope everyone
> follow this vulnerability evaluation principle next time. I'm sure this is
> good for us ;)
>

I forgot to ask what should we do for this bug.
Thank you for your suggestions!

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e0160c2be5ffc5404f2d459da--