FAQ
Hello,

Without arguing again about the """fix""" for the memory corruption
discovered earlier this summer and without anyone able to reproduce
with a medium size script, _why_ in the world one applies this fix to
the 5.0 branche?

5.0.5 was supposed to be a _security_ fix release only. I do know many
people who will upgrade and they do have tousands of lines of codes
wrote by many people. Do you really think the answers given in the
various bug reports (http://bugs.php.net/bug.php?id=34468) is good?

And please, do not tell me to come with a patch to fix this problem,
the fix should have not been applied to 5.0.5, period.

Any chance to roll it again without the fix? The fix is not listed in
the NEWS neither in the Changelog.

I know that the chance to get that fixed is null, but I would like to
hear some valid explanations besides the common arrogant answers.

Regards,

--Pierre

Search Discussions

  • Zeev Suraski at Sep 12, 2005 at 2:39 pm

    At 01:54 12/09/2005, Pierre Joye wrote:
    Hello,

    Without arguing again about the """fix""" for the memory corruption
    discovered earlier this summer and without anyone able to reproduce
    with a medium size script, _why_ in the world one applies this fix to
    the 5.0 branche?

    5.0.5 was supposed to be a _security_ fix release only. I do know many
    people who will upgrade and they do have tousands of lines of codes
    wrote by many people. Do you really think the answers given in the
    various bug reports (http://bugs.php.net/bug.php?id=34468) is good?

    And please, do not tell me to come with a patch to fix this problem,
    the fix should have not been applied to 5.0.5, period.

    Any chance to roll it again without the fix? The fix is not listed in
    the NEWS neither in the Changelog.

    I know that the chance to get that fixed is null, but I would like to
    hear some valid explanations besides the common arrogant answers.
    Pierre,

    I don't think you're going to get a very good answer here. It boils down
    to what you already know - it's a bug which results in corruption, and
    that's the only way to fix it. The common decision was that it's more
    important to fix this bug than to maintain compatibility, and this even
    resulted in a new PHP 'family' (4.4). It's one of those cases where
    there's no good solution, only a choice of bad solutions.

    Zeev
  • Pierre Joye at Sep 12, 2005 at 2:50 pm

    On 9/12/05, Zeev Suraski wrote:

    I don't think you're going to get a very good answer here. It boils down
    to what you already know - it's a bug which results in corruption, and
    that's the only way to fix it. The common decision was that it's more
    important to fix this bug than to maintain compatibility, and this even
    resulted in a new PHP 'family' (4.4). It's one of those cases where
    there's no good solution, only a choice of bad solutions.
    4.4.0, correct and I do accept that. but not in 5.0.5. Derick applied
    the patch to 5.1 not to 5.0.5. We did agree to apply it there and not
    in bug fix releases (and not in security release). Or can you point me
    to the common decision? ;)

    The bad solution is to do not communicate about that. Reading the
    announce of 5.0.5, the only real problem was xml_rpc... If one has
    asked to apply the fix to 5.0.5, I'm pretty sure nobody will agree to
    add this fatal error.

    Regards,

    --Pierre
  • Andi Gutmans at Sep 13, 2005 at 12:33 am
    Hey Pierre,

    Mini releases are not only for security fixes. We also do bug fixes,
    and sometimes even minor functionality (like a new function) which
    has very low risk of breaking anything. I don't think 5.0.5 is
    different from that.
    I do think we could probably be better at communicating these kind of
    breakages. Question is wether we should just try harder, or if you
    have some other concrete ideas which would be easy to implement and stick to?

    Andi
    At 07:50 AM 9/12/2005, Pierre Joye wrote:
    On 9/12/05, Zeev Suraski wrote:

    I don't think you're going to get a very good answer here. It boils down
    to what you already know - it's a bug which results in corruption, and
    that's the only way to fix it. The common decision was that it's more
    important to fix this bug than to maintain compatibility, and this even
    resulted in a new PHP 'family' (4.4). It's one of those cases where
    there's no good solution, only a choice of bad solutions.
    4.4.0, correct and I do accept that. but not in 5.0.5. Derick applied
    the patch to 5.1 not to 5.0.5. We did agree to apply it there and not
    in bug fix releases (and not in security release). Or can you point me
    to the common decision? ;)

    The bad solution is to do not communicate about that. Reading the
    announce of 5.0.5, the only real problem was xml_rpc... If one has
    asked to apply the fix to 5.0.5, I'm pretty sure nobody will agree to
    add this fatal error.

    Regards,

    --Pierre

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Pierre Joye at Sep 13, 2005 at 10:36 am
    Hi Andi,

    On 9/13/05, Andi Gutmans wrote:
    Mini releases are not only for security fixes. We also do bug fixes,
    and sometimes even minor functionality (like a new function) which
    has very low risk of breaking anything. I don't think 5.0.5 is
    different from that.
    As far as (http://bugs.php.net/bug.php?id=34468) exists and have many
    little brothers, I do think 5.0.5 is very different from that.
    I do think we could probably be better at communicating these kind of
    breakages. Question is wether we should just try harder, or if you
    have some other concrete ideas which would be easy to implement and stick to?
    The implementation is fine, a bug is fixed (whether I had it or not
    does not matter ;). About trying harder, I will say trying, not
    bettter, harder, but only trying.

    My plan before 4.4.0 and 5.1 releases was about being more carefull.
    Not like I did not say anything or tried to convince those "STFU"
    people to do so.

    The steps:

    - Do not mix security fixes and BC breaks, this is the worst thing one can do.

    - Do not move from no warning to a fatal error without an intermediate
    version. For example,
    5.0.5 will only raise notices, 5.0.6 and up will have the required behaviors.

    - In any case, it should be wroten in a prominent place both in Changelog and in
    the announce text. For example, the 5.0.5 announce only tells that XML_RPC
    has a security problem, was it on purpose? bad joke?

    4.4.0 for that matter was better than 5.0.5. At least it does not
    always die. But the announcements, communications, or any other normal
    actions are simply bad, the answers to the bugs report being the
    worst.

    So yes, I have had better solutions (from a user point of view), but
    as you said, it is now too late anyway. But I do not consider that
    S'ingTFU will help us to be better :-)

    Regards,

    --Pierre
  • Derick Rethans at Sep 14, 2005 at 12:34 pm

    On Mon, 12 Sep 2005, Pierre Joye wrote:
    On 9/12/05, Zeev Suraski wrote:

    I don't think you're going to get a very good answer here. It boils down
    to what you already know - it's a bug which results in corruption, and
    that's the only way to fix it. The common decision was that it's more
    important to fix this bug than to maintain compatibility, and this even
    resulted in a new PHP 'family' (4.4). It's one of those cases where
    there's no good solution, only a choice of bad solutions.
    4.4.0, correct and I do accept that. but not in 5.0.5. Derick applied
    the patch to 5.1 not to 5.0.5. We did agree to apply it there and not
    in bug fix releases (and not in security release). Or can you point me
    to the common decision? ;)
    I didn't even apply it to 5.1, otherwise it would have been a notice
    there too.

    Derick

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedSep 11, '05 at 10:54p
activeSep 14, '05 at 12:34p
posts6
users4
websitephp.net

People

Translate

site design / logo © 2022 Grokbase