Bugzilla Bug 230575

php-5.2.6-r2 in the tree, I have yet to test whether the fix for the imap issue
works properly, so if it is ok for you, I'd want to wait with stabilization
until tomorrow evening.
Personally I've tested phpMyAdmin (lighty+fastcgi, apache/mod_php) under high
load, WBB3 (lighty+fastcgi) and roundcube (lighty+fastcgi). Everything works as
expected, no regressions so far.

List of issues fixed:

 * Insecure c-client api calls allow for buffer overflows
   This IMO allows for local code execution (as such bypassing safe_mode etc.)
   and maybe eben remote code execution when processing specially-crafted
   mails.

 * Crash in stream_context_set_params()
   http://bugs.php.net/44712

 * Crash in class PDORow
   Commit msg: "Add check for avoid segfault when trying instantiate
                PDORow manually"

 * Crash (double free) in Dom->setAttributeNode
   http://bugs.php.net/45251
   Commit msg: "fixed bug #45251 (double free or corruption with
                setAttributeNode())"

 * Crash in array functions under certain circumstances
   http://bugs.php.net/45312
   Commit msg: "Fixed bug #45312 (Segmentation fault on second request for
                array functions)"

 * Crash related to tick functions
   http://bugs.php.net/45352
   Commit msg: "Fixed bug #45352 (Segmentation fault because of tick function
                on second request)"

 * Possible overflow+crash when dealing with certain math operations
   Commit msg: "Fixed overflow crash (at least on Windows) in div_function
                with LONG_MIN / -1"
   No idea in what exact circumstances this happens, whether it might allow
   for code execution or whether it is reproducable on Linux at all.

 * ext/pcre: Heap-based buffer overflow (CVE-2008-2371) in bundled libpcre
   see Gentoo bug 228091

Security, feel free to do your thing and call for stabilization.

I've not been able to create a test case for the c-client issue, and I just
discovered there are at least two other places where similar overflows can
occur (which are not addressed by the patch). So I'd suggest to use this as an
intermediate solution, we're waiting on another fix anyway, so -r3 is going to
happen in any case.

Arches, please test and mark stable:
=dev-lang/php-5.2.6-r2
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"

ppc and ppc64 done

amd64 stable, tested with mythweb, phpmyadmin, phpsysinfo, ampache...

Hello,

what about this: http://bugs.gentoo.org/230809

(In reply to comment #5)
> what about this: http://bugs.gentoo.org/230809
It's not a regression (I just verified) and as such, it should not prevent a
new version going stable for security reasons.
BTW, I'm also assuming that it is related to libtool-2.2* and as such doesn't
affect stable anyway.
Use FEATURES=-stricter as a workaround. And let's keep the rest of this
discussion in the relevant bug. :)

x86 stable

alpha/ia64/sparc stable

I forgot to bump the dependency on c-client to 2006k in php-5.2.6-r2, I just
committed the fixed *DEPEND. Keyword-wise this is no problem as all arches,
which have -r2 stable also have the required c-client version stable.

sh/arm/s390: You need to stabilize >=net-libs/c-client-2006k before stabling
this version of php (or any later).

hppa is fine, as far as I can see.

Stable for HPPA. Removing the blocking bug as it is easily worked around by not
setting FFLAGS.