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
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-1239Long 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
Hi Joe,
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 ...
Thank you for the comment. It helps :)
It would be nice to have patch, I agree.
I don't have luxury to write code that would not be used...
I don't mind to have vote for proposed patch and improve, though.
Is a patch must have requirement for RFC?
I think it worth to agree what we should have, then decide/write code
like timing safe string comparison.
I wouldn't write number of timing safe functions to compare their
performance unless it was decided to include.
https://github.com/yohgaki/php-src/compare/PHP-5.6-rfc-hash-compare
I hope you change your mind.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
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.
All of voters other than me voted no, so far.
I would like hear the reason.
We can make future PHP handles all encoding. How many of you prefer this
options?
To be honest, I'm +1 for this. However, it seems there are many people
against it.
e.g. Encoding parameter/property seems to have many objections.
Since this is technical discussion, objection without reason is not
constructive.
Thank you for sharing your opinions!
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
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.All of voters other than me voted no, so far.
I would like hear the reason.
The proper way to handle this is language Unicode support. Having yet
another "UTF-8" extension is not a long term solution.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
Hi Derick,
All of voters other than me voted no, so far.
I would like hear the reason.The proper way to handle this is language Unicode support. Having yet
another "UTF-8" extension is not a long term solution.
Although, it aims to replace existing mbstring, I can agree with your
opinion.
If PHP is going to support Unicode fully, i.e. have encoding
parameter/property,
then it would be good solution. Just one quick question, what do you think
about
encoding parameter/property? Functions like fgetcsv() needs to specify
encoding,
but it seems many people against it.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Yasuo Ohgaki wrote:
The proper way to handle this is language Unicode support. Having *yet
another* "UTF-8" extension is not a long term solution.
Although, it aims to replace existing mbstring, I can agree with your opinion.
If PHP is going to support Unicode fully, i.e. have encoding parameter/property,
then it would be good solution. Just one quick question, what do you think about
encoding parameter/property? Functions likefgetcsv()needs to specify encoding,
but it seems many people against it.
The first thing that has to be decided is if the whole core is simply UTF8. To
my mind this is the most practical approach, so that fgetcsv() will work only
with UTF8. This then moves the problem of coding to where it should be, on the
'connection', so either everything is stored as unicode and transcoded when
being saved, or your streaming adds the transcoding. Conversion to lower/upper
case would be the same sort of filter on the data stream.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
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-1239Long 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.
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.
Thanks,
Nikita
Hi Nikita,
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
Hi all,
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 ;)
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
Short term: Multibyte Char Handling
https://wiki.php.net/rfc/multibyte_char_handling
Add functions required to resolve security issues. CVE-2014-1239https://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