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

Hi Nikita, On Fri, Feb 14, 2014 at 6:14 AM, Nikita Popov <nikita.ppv@gmail.com> wrote: > I voted no on both RFCs, for about the same reasons as Joe. Voting on > mbstring-ng at this point makes about zero sense, given that the code is > nowhere even near being ready for merging into PHP. > > Regarding the other RFC for the addition of new mb_* function, I'd like to > start off by saying that I disagree with your premise that this is a > security vulnerability that needs to be fixed quickly and across all > supported versions. As far as I can see the issue is somebody using > addslashes() in an inappropriate context - this is a vulnerability in the > application, not PHP. This is a lot like saying that we have an RCE > vulnerability in eval() because someone had the genius idea of putting > eval($_GET['str']) in his or her code. > > As this constitutes no critical or non-critical vulnerability in PHP, any > function additions should only happen in PHP 5.6 and not PHP 5.4+. > > Apart from this, the RFC is very low on technical detail. It doesn't have > a patch, which is not a problem *per-se*, however it doesn't have any > implementational details whatsoever. While I guess that the addslashes part > is rather straightforward, I'm sure that addcslashes, escapeshellarg and > var_export are less trivial. > > An example of what is unclear: The addclashes functions has a charlist > parameter. Currently chars with ASCII <32, >126 are encoded in octal - what > will happen here with multibyte chars? Will you encode the unicode code > point in octal? Are there even systems that support that? And what about > the range feature? Will this cover unicode code point ranges now? Etc. > > This RFC probably has merit, but right now there is not enough detail to > make an informed decision. > Very informative comment. Thank you! Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net