Summary: | =dev-lang/php-4*: Multiple vulnerabilities | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Christian Hoffmann (RETIRED) <hoffie> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | andrei.ivanov, php-bugs |
Priority: | High | Keywords: | PMASKED |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://cvs.php.net/viewvc.cgi/php-src/NEWS?revision=1.1247.2.920.2.243&view=markup&pathrev=PHP_4_4 | ||
Whiteboard: | B? [glsa] | ||
Package list: | Runtime testing required: | --- |
Description
Christian Hoffmann (RETIRED)
2007-08-16 22:32:12 UTC
php-4.4.8_pre20070816 which is supposed to fix these issues is in the tree now. Arches please test and mark stable. Target keywords are: php-4.4.8_pre20070816.ebuild:KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86 ~x86-fbsd" grep FAIL `qlogs -f php-4.4.8` * Waiting for 361 to finish... Done! FAIL Handling of max_input_nesting_level being reached [tests/basic/027.phpt] FAIL Bug #35239 (Objects can lose references) [tests/lang/bug35239.phpt] FAIL Bug #24155 (gdImageRotate270 rotation problem). [ext/gd/tests/bug24155.phpt] FAIL Bug #27582 (ImageFillToBorder() on alphablending image looses alpha on fill color) [ext/gd/tests/bug27582_1.phpt] FAIL Bug #16069 [ext/iconv/tests/bug16069.phpt] FAIL pspell basic tests (warning: may fail with pspell/aspell < GNU Aspell 0.50.3) [ext/pspell/tests/01pspell_basic.phpt] FAIL Bug #41655: open_basedir bypass via glob() [ext/standard/tests/file/bug41655_1.phpt] FAIL Invalid format type validation [ext/standard/tests/strings/unpack.phpt] FAILED TEST SUMMARY Stable for HPPA. (In reply to comment #3) > grep FAIL `qlogs -f php-4.4.8` > * Waiting for 361 to finish... Done! > FAIL Handling of max_input_nesting_level being reached [tests/basic/027.phpt] Cannot reproduce this one, neither in portage environment nor with the usual run-tests.php. > FAIL Bug #41655: open_basedir bypass via glob() [ext/standard/tests/file/bug41655_1.phpt] This test fails if the test is run under /tmp (it assumes it is run somwhere else)... so for me this test PASSes in portage environment; do you have PORTAGE_TMPDIR=/tmp by chance? Anyway, I really don't think it can be broken on one arch and work on another. All other test failures are either because of portage environment or failed in previous releases as well... Stable on x86 sparc stable. ppc stable amd64 stable alpha/ia64 stable ppc64 stable I vote yes - this is a (sadly) major package, and these are longstanding, serious problems. voting yes too, we'll do a global glsa with bug #180556 and bug #179158. Ok, until now more vulnerabilities have been found (just to name some examples -- iconv* and dl() stuff, see php-5) and as discussed on IRC with the rest of the PHP team and security, we are going to mask =dev-lang/php-4* around Oct 18th. It's impossible for us to keep up with security problems as php-4 upstream is pretty inactive. Security, I guess you want to send a mask GLSA in this case. =dev-lang/php-4* and related packages in p.mask now. So what's the solution, just upgrade to php5? I have to choose between having an insecure server or the web sites that require php4 not working at all... :-( (In reply to comment #15) > I have to choose between having an insecure server or the web sites that > require php4 not working at all... :-( PHP 4 will be discontinued upstream in some time anyway, we highly recommend you upgrade to PHP 5. (In reply to comment #15) > So what's the solution, just upgrade to php5? Yes, that's the only solution since upstream development of PHP4 is dead. http://www.gentoo.org/news/en/gwn/20071008-newsletter.xml#doc_chap1 http://forums.gentoo.org/viewtopic-t-597851.html Actually we released GLSA 200710-02 [1] which tags PHP < 5.2.4_pxxxxxx as vulnerable. Since glsa-check isn't slot-aware, it considers PHP-4 vulnerable too. So I don't see the point in releasing another GLSA for PHP-4, I think we should just close this bug now. Any objections? [1] http://www.gentoo.org/security/en/glsa/glsa-200710-02.xml (In reply to comment #18) > Actually we released GLSA 200710-02 [1] which tags PHP < 5.2.4_pxxxxxx as > vulnerable. Since glsa-check isn't slot-aware, it considers PHP-4 vulnerable > too. So I don't see the point in releasing another GLSA for PHP-4, I think we > should just close this bug now. Any objections? ACK. We could have made that clearer in the GLSA, though. Should we update it with a sentence in the resolution? A note to php4 users would be nice I guess. (In reply to comment #20) > A note to php4 users would be nice I guess. > http://forums.gentoo.org/viewtopic-t-597851.html This post has also been seen on gentoo-announce on October 16th. Honestly, I don't see what we could add to that... Finally closing, there was GLSA 200710-02, plus the post on forums and gentoo-announce (comment #21). Feel free to reopen if you disagree, but honestly I think users have been warned enough... (In reply to comment #2) > Arches please test and mark stable. Target keywords are: > > php-4.4.8_pre20070816.ebuild:KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 s390 > sh sparc x86 ~x86-fbsd" > how about mips? I can't see mips in the list but I really need run it on an mips server. thanks. PHP 4.x is unsupported upstream and in Gentoo, sorry. You could try asking the mips people directly in another bug. Just for reference, php-4 has been removed from the tree entirely now. It is still available in the "php-4" overlay available via layman. Keep in mind that it is completely unsupported by security, so use it at your own risk... |