FAQ
hirokawa Wed Oct 22 10:14:06 2003 EDT

Modified files:
/php-src/main rfc1867.c
/php-src/ext/mbstring mbstring.c mbstring.h
Log:
name/value in multipart/form-date will be converted into internal encoding when mbstring.encoding_translation is On.

Search Discussions

  • Rasmus Lerdorf at Oct 23, 2003 at 1:43 am
    Are you committing this to 4.3 as well?
    On Wed, 22 Oct 2003, Rui Hirokawa wrote:

    hirokawa Wed Oct 22 10:14:06 2003 EDT

    Modified files:
    /php-src/main rfc1867.c
    /php-src/ext/mbstring mbstring.c mbstring.h
    Log:
    name/value in multipart/form-date will be converted into internal encoding when mbstring.encoding_translation is On.
  • Rui Hirokawa at Oct 25, 2003 at 3:07 am
    Yes, I have plan to commit to 4.3 branch.
    Ilia, is it possible to commit ?

    Rui

    On Thu, 23 Oct 2003 10:43:16 +0900 (JST)
    Rasmus Lerdorf wrote:
    Are you committing this to 4.3 as well?
    On Wed, 22 Oct 2003, Rui Hirokawa wrote:

    hirokawa Wed Oct 22 10:14:06 2003 EDT

    Modified files:
    /php-src/main rfc1867.c
    /php-src/ext/mbstring mbstring.c mbstring.h
    Log:
    name/value in multipart/form-date will be converted into internal encoding when mbstring.encoding_translation is On.

    --
    Rui Hirokawa <rui_hirokawa@ybb.ne.jp>
  • Ilia Alshanetsky at Oct 25, 2003 at 4:32 pm
    My appologies for the delayed response (I see that the patch was commited).
    After reviewing the patch I would very much prefer if you would revert it and
    wait till PHP 4.3.5 (ot whatever the next release will be) with it.

    Ilia
    On October 24, 2003 11:08 pm, Rui Hirokawa wrote:
    Yes, I have plan to commit to 4.3 branch.
    Ilia, is it possible to commit ?

    Rui
  • Rasmus Lerdorf at Oct 25, 2003 at 10:22 pm
    And continue breaking licenses knowingly?
    On Sat, 25 Oct 2003, Ilia Alshanetsky wrote:

    My appologies for the delayed response (I see that the patch was commited).
    After reviewing the patch I would very much prefer if you would revert it and
    wait till PHP 4.3.5 (ot whatever the next release will be) with it.

    Ilia
    On October 24, 2003 11:08 pm, Rui Hirokawa wrote:
    Yes, I have plan to commit to 4.3 branch.
    Ilia, is it possible to commit ?

    Rui
  • Ilia Alshanetsky at Oct 25, 2003 at 10:31 pm

    On October 25, 2003 06:22 pm, Rasmus Lerdorf wrote:
    And continue breaking licenses knowingly?
    That patch does not fix licensing issues, it merely adds a feature, the
    license fix is not there...

    Patch log:
    name/value in multipart/form-date will be converted into internal encoding
    when mbstring.encoding_translation is On.

    Ilia
  • Rasmus Lerdorf at Oct 25, 2003 at 11:14 pm

    On Sat, 25 Oct 2003, Ilia Alshanetsky wrote:
    On October 25, 2003 06:22 pm, Rasmus Lerdorf wrote:
    And continue breaking licenses knowingly?
    That patch does not fix licensing issues, it merely adds a feature, the
    license fix is not there...

    Patch log:
    name/value in multipart/form-date will be converted into internal encoding
    when mbstring.encoding_translation is On.
    Ah, thought it was the other patch. However, I wouldn't call the above a
    new feature. That one is a bug fix as it was an oversight to not also
    convert form fields in multipart posts.

    -Rasmus
  • Ilia Alshanetsky at Oct 26, 2003 at 4:41 am

    On October 25, 2003 07:14 pm, Rasmus Lerdorf wrote:
    Ah, thought it was the other patch. However, I wouldn't call the above a
    new feature. That one is a bug fix as it was an oversight to not also
    convert form fields in multipart posts.
    Well, it is a mix of a feature & a bug fix. The bug if we decide to call it
    such is by no means critical and 2 days before the release time is not a time
    to make any non critical changes simply because there is no time to test
    them. rfc1867.c is very sensitive code which previously had a number of
    security faults at least 1 directly caused by mbstring related changes. It is
    my opinion such changes have no place this late in the release cycle.

    Ilia
  • Moriyoshi Koizumi at Oct 26, 2003 at 6:21 am

    Ilia Alshanetsky wrote:
    On October 25, 2003 07:14 pm, Rasmus Lerdorf wrote:
    Ah, thought it was the other patch. However, I wouldn't call the above a
    new feature. That one is a bug fix as it was an oversight to not also
    convert form fields in multipart posts.
    Well, it is a mix of a feature & a bug fix. The bug if we decide to call it
    such is by no means critical and 2 days before the release time is not a time
    to make any non critical changes simply because there is no time to test

    I kind of agree with Ilia here. It'd be a bad idea to have GPC-related
    patch during the RC period, although the modified parts are all companied
    with #ifdef's as far as I'm concerned.
    them. rfc1867.c is very sensitive code which previously had a number of
    security faults at least 1 directly caused by mbstring related changes. It is
    my opinion such changes have no place this late in the release cycle.
    Just want to make it clear, the past problem you mentioned related to
    mbstring is not a security fault, you know.

    Moriyoshi
  • Rui Hirokawa at Oct 26, 2003 at 7:20 am
    Ilia,

    I appreciate your continious effort about QC process.
    GPC bug in rfc1867.c is not critical one, and I agree with you
    it is not preferable in the final RC process.
    I will revert my GPC related patch in a couple of hours.

    But, I shoudn't revert an another license related patch
    as shown below because the license compatibility has priority.

    +2003-10-25 Rui Hirokawa <rui_hirokawa@ybb.ne.jp>
    +
    + * (PHP_4_3)
    + ext/mbstring/mbstring.dsp:
    + fixed windows build.
    +
    + * (PHP_4_3)
    + ext/mbstring/README.libmbfl
    + ext/mbstring/config.m4
    + ext/mbstring/cp932_table.h
    + ext/mbstring/html_entities.c
    + ext/mbstring/mbfilter.c
    + ext/mbstring/mbfilter.h
    + ext/mbstring/mbfilter_cn.c
    + ext/mbstring/mbfilter_cn.h
    + ext/mbstring/mbfilter_ja.c
    + ext/mbstring/mbfilter_ja.h
    + ext/mbstring/mbfilter_kr.c
    + ext/mbstring/mbfilter_kr.h
    + ext/mbstring/mbfilter_ru.c
    + ext/mbstring/mbfilter_ru.h
    + ext/mbstring/mbfilter_tw.c
    + ext/mbstring/mbfilter_tw.h
    + ext/mbstring/mbregex.c
    + ext/mbstring/mbregex.h
    + ext/mbstring/mbstring.c
    + ext/mbstring/mbstring.dsp
    + ext/mbstring/mbstring.h
    + ext/mbstring/unicode_table.h
    + ext/mbstring/unicode_table_cn.h
    + ext/mbstring/unicode_table_ja.h
    + ext/mbstring/unicode_table_kr.h
    + ext/mbstring/unicode_table_ru.h
    + ext/mbstring/unicode_table_tw.h:
    + mbfilter is replaced with libmbfl to maintain the licence compatibility.
    + mbregex.[ch] is moved to mbregex/ for the same reason.
    +

    On Sun, 26 Oct 2003 00:46:29 -0400
    Ilia Alshanetsky wrote:
    On October 25, 2003 07:14 pm, Rasmus Lerdorf wrote:
    Ah, thought it was the other patch. However, I wouldn't call the above a
    new feature. That one is a bug fix as it was an oversight to not also
    convert form fields in multipart posts.
    Well, it is a mix of a feature & a bug fix. The bug if we decide to call it
    such is by no means critical and 2 days before the release time is not a time
    to make any non critical changes simply because there is no time to test
    them. rfc1867.c is very sensitive code which previously had a number of
    security faults at least 1 directly caused by mbstring related changes. It is
    my opinion such changes have no place this late in the release cycle.

    Ilia

    --
    Rui Hirokawa <rui_hirokawa@ybb.ne.jp>
  • Moriyoshi Koizumi at Oct 26, 2003 at 7:30 am
    Rui, wasn't there any agreement with the author of libmbfl that still
    allows us to keep the modified version in the 4.3 branch? Unless there's
    something obvious, we'd be better off replacing them by the safer stuff
    however.

    Moriyoshi

    Rui Hirokawa wrote:
    Ilia,

    I appreciate your continious effort about QC process.
    GPC bug in rfc1867.c is not critical one, and I agree with you
    it is not preferable in the final RC process.
    I will revert my GPC related patch in a couple of hours.

    But, I shoudn't revert an another license related patch
    as shown below because the license compatibility has priority.
  • Rui Hirokawa at Oct 26, 2003 at 8:19 am
    Moriyoshi,

    Yes, there was a temporary agreement that allows us to release the current version in the 4.3 branch until new implementation has stability.

    But, I think replacing libmbfl with mbfilter.* in PHP 4.3.4 is preferable because,
    1. license problem should be solved as quickly as possible.
    2. The differences of libmbfl and the current implementation are
    quite small because the new implementation is based on the current
    implementation.
    3. the new implementation with libmbfl is well tested in PHP 5
    since last August.
    4. the new implementation was already confirmed
    to pass the all unit tests in ext/mbstring/tests/*.

    Rui

    On Sun, 26 Oct 2003 16:31:06 +0900
    Moriyoshi Koizumi wrote:
    Rui, wasn't there any agreement with the author of libmbfl that still
    allows us to keep the modified version in the 4.3 branch? Unless there's
    something obvious, we'd be better off replacing them by the safer stuff
    however.

    Moriyoshi

    Rui Hirokawa wrote:
    Ilia,

    I appreciate your continious effort about QC process.
    GPC bug in rfc1867.c is not critical one, and I agree with you
    it is not preferable in the final RC process.
    I will revert my GPC related patch in a couple of hours.

    But, I shoudn't revert an another license related patch
    as shown below because the license compatibility has priority.

    --
    Rui Hirokawa <rui_hirokawa@ybb.ne.jp>
  • Moriyoshi Koizumi at Oct 26, 2003 at 8:44 am

    Rui Hirokawa wrote:

    2. The differences of libmbfl and the current implementation are
    quite small because the new implementation is based on the current
    implementation.
    Yeah, I hope the impact is just as ignorable as of a mere bug fix, but I
    should also mention that I'm not that pretty sure how it actually does
    while most of the work concerning the reconstruction of libmbfl from what
    used to be here in the 4.x branch was done by me.
    3. the new implementation with libmbfl is well tested in PHP 5
    since last August.
    I doubt it somewhat, since we haven't got no handful of reports from who
    put beta with libmbfl in action.
    4. the new implementation was already confirmed
    to pass the all unit tests in ext/mbstring/tests/*.
    The fact is that I had to patch mbstring.c and rewrite some tests to keep
    them neat.

    Anyway, the license really is the deal, we should move on.

    Moriyoshi
  • Derick Rethans at Oct 27, 2003 at 9:12 am

    On Sun, 26 Oct 2003, Moriyoshi Koizumi wrote:

    3. the new implementation with libmbfl is well tested in PHP 5
    since last August.
    I doubt it somewhat, since we haven't got no handful of reports from who
    put beta with libmbfl in action.
    Yeah, I'm also doubting this. Let's not do it for 4.3.4 please as it
    requires atleast one more RC.

    Derick

    --
    "Interpreting what the GPL actually means is a job best left to those
    that read the future by examining animal entrails."
    -------------------------------------------------------------------------
    Derick Rethans http://derickrethans.nl/
    International PHP Magazine http://php-mag.net/
    -------------------------------------------------------------------------
  • Rasmus Lerdorf at Oct 28, 2003 at 6:56 am
    At this point we are then knowingly and blatantly violating the license.
    This would be extremely hard to justify if anybody calls us on it.

    -Rasmus
    On Mon, 27 Oct 2003, Derick Rethans wrote:
    On Sun, 26 Oct 2003, Moriyoshi Koizumi wrote:

    3. the new implementation with libmbfl is well tested in PHP 5
    since last August.
    I doubt it somewhat, since we haven't got no handful of reports from who
    put beta with libmbfl in action.
    Yeah, I'm also doubting this. Let's not do it for 4.3.4 please as it
    requires atleast one more RC.

    Derick
  • Ilia Alshanetsky at Oct 27, 2003 at 5:03 pm
    To summarize this discussion could you please verify that the patch now
    committed does in fact completely fix the licensing issue. From some of the
    previous comments (maybe I misunderstood) it seems that new code is too not
    entirely license safe (??).

    Thanks,

    Ilia

    P.S. Did you see the patch by Joe Orton on internals, it seems that there is
    a compile problem with mbregex.
  • Moriyoshi Koizumi at Oct 27, 2003 at 5:45 pm

    Ilia Alshanetsky wrote:

    To summarize this discussion could you please verify that the patch now
    committed does in fact completely fix the licensing issue. From some of the
    previous comments (maybe I misunderstood) it seems that new code is too not
    entirely license safe (??).
    Rui once had a talk with the author of mbfilter about this forked stuff
    (libmbfl) and the author appears to have accepted our choice.

    From what comment did you think it is not completely free from this
    issue? (if you can remimd me of any)

    Moriyoshi
  • Ilia Alshanetsky at Oct 27, 2003 at 5:48 pm

    On October 27, 2003 12:44 pm, Moriyoshi Koizumi wrote:
    From what comment did you think it is not completely free from this
    issue? (if you can remimd me of any)
    I guess the bit about temporary agreements, etc... through me off. Anyhow if
    we are clear license wise, then great. I'll talk with edin and try to get RC3
    rolled out either this evening or tomorrow morning.

    Ilia
  • Moriyoshi Koizumi at Oct 27, 2003 at 5:57 pm

    Ilia Alshanetsky wrote:
    On October 27, 2003 12:44 pm, Moriyoshi Koizumi wrote:
    From what comment did you think it is not completely free from this
    issue? (if you can remimd me of any)
    I guess the bit about temporary agreements, etc... through me off. Anyhow if
    we are clear license wise, then great. I'll talk with edin and try to get RC3
    rolled out either this evening or tomorrow morning.
    Ah, I see. What he mentioned as a "temporary agreement" is that the
    author permitted us to release that mutant till the libmbfl is confirmed
    to be stable. Now we have a clean one, I reckon there should be no such
    concern like you have.

    Thanks,

    Moriyoshi
  • Rui Hirokawa at Oct 27, 2003 at 10:20 pm
    I think the patch commited now fix the licensing incompatibility
    as Moriyoshi said.

    Rui

    On Mon, 27 Oct 2003 13:09:18 -0400
    Ilia Alshanetsky wrote:
    To summarize this discussion could you please verify that the patch now
    committed does in fact completely fix the licensing issue. From some of the
    previous comments (maybe I misunderstood) it seems that new code is too not
    entirely license safe (??).

    Thanks,

    Ilia

    P.S. Did you see the patch by Joe Orton on internals, it seems that there is
    a compile problem with mbregex.
    --
    Rui Hirokawa <rui_hirokawa@ybb.ne.jp>
  • Ilia Alshanetsky at Oct 27, 2003 at 10:25 pm
    Perfect, thanks for letting me know.
    On October 27, 2003 05:20 pm, Rui Hirokawa wrote:
    I think the patch commited now fix the licensing incompatibility
    as Moriyoshi said.

    Rui
  • Ilia Alshanetsky at Oct 26, 2003 at 4:33 pm

    On October 26, 2003 02:20 am, Rui Hirokawa wrote:
    But, I shoudn't revert an another license related patch
    as shown below because the license compatibility has priority.
    There is no argument about the license fix patch, it is a necessary evil. I
    will make RC3 on Monday with this patch and if no bugs appear, go forth with
    4.3.4 final 1 week from Monday.

    Ilia
  • Rui Hirokawa at Oct 26, 2003 at 12:42 am
    I think it is a kind of bug fix because,
    1. name field of multipart/form was not converted into internal encoding.
    This behavior is different from the usual GPC conversion performed by
    mbstr_treat_data() and it might makes confusion for the users.
    2. auto-detection might be fail because auto-detection was performed per
    variables. It should be performed using the whole form data as in
    mbstr_treat_data().
    3. form field was converted into internal encoding even if
    mbstring.http_input is set to 'pass'.
    4.auto detection was performed even if mbstring.http_input is set to
    'pass' or any valid encoding .

    And the license fix is an another patch as Rasmus said.

    Rui

    On Sat, 25 Oct 2003 18:36:41 -0400
    Ilia Alshanetsky wrote:
    On October 25, 2003 06:22 pm, Rasmus Lerdorf wrote:
    And continue breaking licenses knowingly?
    That patch does not fix licensing issues, it merely adds a feature, the
    license fix is not there...

    Patch log:
    name/value in multipart/form-date will be converted into internal encoding
    when mbstring.encoding_translation is On.

    Ilia
    --
    Rui Hirokawa <rui_hirokawa@ybb.ne.jp>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-cvs @
categoriesphp
postedOct 22, '03 at 2:14p
activeOct 28, '03 at 6:56a
posts23
users6
websitephp.net

People

Translate

site design / logo © 2019 Grokbase