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.
GLSA 200811-05, thanks everyone, especially hoffie.