Funda Wang has alerted us to the fact that PHP 5.3.9 introduced a new security vulnerability. This is due to an incorrect fix to CVE-2011-4885 introduced in the last update. Funda has already noted that an update to PHP 5.3.10 to fix this has been built and is ready for testing. Just one suggestion, I recommend we wait for Mandriva to issue their advisory for this before giving the final validation, just to make sure we have rebuilt all dependent packages that need to be rebuilt for this update, as well as any that need to be rebuilt to match updated MDV versions (for upgrading from MDV 2010.2).
CC: (none) => dmorganec, fundawang, kristoffer.grundstrom1983, lists.jjorge, stormi, thomas
getting exclusive lock on rpm A requested package cannot be installed: php-cgi-5.3.10-0.2.mga1.x86_64 (due to unsatisfied php-ini[>= 5.3.10]) Continue installation anyway? (Y/n) Php-cgi also needs a rebuild
Actually the issue is that the php-ini package hasn't been rebuilt yet (php-cgi is generated by the php SRPM). I think they moved php-ini into the php SRPM in Cauldron. It would be sensible to do the same for Mageia 1 (the same was already done for apache-mod_php in the last update).
Reassigning to maintainer since this isn't ready for QA. Thomas, according to this: https://wiki.mageia.org/en/Updates_policy#Maintainer_.28or_any_interested_packager.29 The %release should be 1, not 0. I believe the reason for this was to ensure our release tag will be higher than Mandriva's, because we know theirs will be 0.x.
Assignee: qa-bugs => thomas
the package has been updated to release 1, no subrel. same with php-ini I did not merge the php-ini with php as in cauldron. We shouldn't change more than needed in a released distro I think it's now ready to test
Status: NEW => ASSIGNEDAssignee: thomas => qa-bugs
So, what do we have to test? Would somebody please list what has been updated at least.
The php and php-ini SRPMS have been updated, which provide the apache-mod_php, libphp5_common5, and php-* RPMS in updates_testing.
Thankyou David (again) Thomas, I know I asked last time too, would you please follow the updates policy for future updates to Mageia 1. You can find it on the wiki here.. https://wiki.mageia.org/en/Updates_policy#Maintainer_.28or_any_interested_packager.29 It not only prevents unnecessary delays but also ensures QA can do their job properly. Thankyou.
How are php-accelerator, php-apc etc affected by this update, alot more needed to be rebuilt last time php was updated?
Talking on IRC there is still some uncertainty what exactly needs rebuilding for this update to be pushed. I am assigning back to Thomas until this is fully ready for QA to avoid the confusion we had last time. When it is ready please reassign to QA with an advisory of what has been updated. We want to avoid pushing things separately which need to go together and causing breakage for our users so it is much safer to do this all at once. I've added QA in CC
CC: (none) => qa-bugsAssignee: qa-bugs => thomas
I checked the mandriva updates and they are still on 5.3.9 for 2011 They did not update anything php related on cooker to 5.3.10 besides php itself
Blocks: (none) => 4390
I think we've waited long enough for Mandriva. Judging from Comment 10, it sounds like we'll be OK with what Thomas has already built. I think we should let QA have this one once the apache update (Bug 4092) is pushed.
This update addresses CVE-2011-4885 Mandriva has not updated php-5.3.0 in 2011. Funda Wang has done the upgrade to 5.3.10 in mag1 to resolve CVE-2011-4885. I have upgraded php-ini to go with this. I don't see any other rebuilds needed (nobody complained in cauldron nor has cooker rebuilt other php-packages based on php-5.3-10) I did some preliminary testing: I added the updates_testing as a source, did urpmi php and it installed the packages, including the php-ini I used the kolab-webadmin interface and made some changed to the setting. This is now ready for QA to test.
Assigning to QA per maintainer's instructions. Thanks Thomas.
Assignee: thomas => qa-bugs
Advisory: ======================== Updated php packages fix security vulnerability: PHP before 5.3.9 computes hash values for form parameters without restricting the ability to trigger hash collisions predictably, which allows remote attackers to cause a denial of service (CPU consumption) by sending many crafted parameters (CVE-2011-4885). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4885 ======================== Updated packages in core/updates_testing: ======================== libphp5_common5-5.3.10-1.mga1 php-bcmath-5.3.10-1.mga1 php-bz2-5.3.10-1.mga1 php-calendar-5.3.10-1.mga1 php-cgi-5.3.10-1.mga1 php-cli-5.3.10-1.mga1 php-ctype-5.3.10-1.mga1 php-curl-5.3.10-1.mga1 php-dba-5.3.10-1.mga1 php-devel-5.3.10-1.mga1 php-doc-5.3.10-1.mga1 php-dom-5.3.10-1.mga1 php-enchant-5.3.10-1.mga1 php-exif-5.3.10-1.mga1 php-fileinfo-5.3.10-1.mga1 php-filter-5.3.10-1.mga1 php-fpm-5.3.10-1.mga1 php-ftp-5.3.10-1.mga1 php-gd-5.3.10-1.mga1 php-gettext-5.3.10-1.mga1 php-gmp-5.3.10-1.mga1 php-hash-5.3.10-1.mga1 php-iconv-5.3.10-1.mga1 php-imap-5.3.10-1.mga1 php-ini-5.3.10-1.mga1 php-intl-5.3.10-1.mga1 php-json-5.3.10-1.mga1 php-ldap-5.3.10-1.mga1 php-mbstring-5.3.10-1.mga1 php-mcrypt-5.3.10-1.mga1 php-mssql-5.3.10-1.mga1 php-mysql-5.3.10-1.mga1 php-mysqli-5.3.10-1.mga1 php-mysqlnd-5.3.10-1.mga1 php-odbc-5.3.10-1.mga1 php-openssl-5.3.10-1.mga1 php-pcntl-5.3.10-1.mga1 php-pdo-5.3.10-1.mga1 php-pdo_dblib-5.3.10-1.mga1 php-pdo_mysql-5.3.10-1.mga1 php-pdo_odbc-5.3.10-1.mga1 php-pdo_pgsql-5.3.10-1.mga1 php-pdo_sqlite-5.3.10-1.mga1 php-pgsql-5.3.10-1.mga1 php-phar-5.3.10-1.mga1 php-posix-5.3.10-1.mga1 php-pspell-5.3.10-1.mga1 php-readline-5.3.10-1.mga1 php-recode-5.3.10-1.mga1 php-session-5.3.10-1.mga1 php-shmop-5.3.10-1.mga1 php-snmp-5.3.10-1.mga1 php-soap-5.3.10-1.mga1 php-sockets-5.3.10-1.mga1 php-sqlite3-5.3.10-1.mga1 php-sybase_ct-5.3.10-1.mga1 php-sysvmsg-5.3.10-1.mga1 php-sysvsem-5.3.10-1.mga1 php-sysvshm-5.3.10-1.mga1 php-tidy-5.3.10-1.mga1 php-tokenizer-5.3.10-1.mga1 php-wddx-5.3.10-1.mga1 php-xml-5.3.10-1.mga1 php-xmlreader-5.3.10-1.mga1 php-xmlrpc-5.3.10-1.mga1 php-xmlwriter-5.3.10-1.mga1 php-xsl-5.3.10-1.mga1 php-zip-5.3.10-1.mga1 php-zlib-5.3.10-1.mga1 from SRPMS: php-5.3.10-1.mga1.i586.rpm php-ini-5.3.10-1.mga1.i586.rpm
Thomas, what happened to apache-mod_php?
What about php-eaccelerator and php-apc? There was far more than php and php-ini needed rebuilding last time.
(In reply to comment #15) > Thomas, what happened to apache-mod_php? It got deleted by accident (partially my fault actually). You can either ask a sysadmin to delete the packages and resubmit the build, or bump the release and resubmit the build.
(In reply to comment #17) > (In reply to comment #15) > > Thomas, what happened to apache-mod_php? > > It got deleted by accident (partially my fault actually). > > You can either ask a sysadmin to delete the packages and resubmit the build, or > bump the release and resubmit the build. OK, I got it deleted and rebuilt. Everything should be fine now.
I tested this and it works fine for my test cases that test php-cgi, apache_mod-php, php-gd, and php-dba from https://bugs.mageia.org/show_bug.cgi?id=3895#c35 (tested on i586).
Fixing the advisory now that apache-mod_php is back on the mirrors. Advisory: ======================== Updated php packages fix security vulnerability: PHP before 5.3.9 computes hash values for form parameters without restricting the ability to trigger hash collisions predictably, which allows remote attackers to cause a denial of service (CPU consumption) by sending many crafted parameters (CVE-2011-4885). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4885 ======================== Updated packages in core/updates_testing: ======================== apache-mod_php-5.3.10-1.mga1 libphp5_common5-5.3.10-1.mga1 php-bcmath-5.3.10-1.mga1 php-bz2-5.3.10-1.mga1 php-calendar-5.3.10-1.mga1 php-cgi-5.3.10-1.mga1 php-cli-5.3.10-1.mga1 php-ctype-5.3.10-1.mga1 php-curl-5.3.10-1.mga1 php-dba-5.3.10-1.mga1 php-devel-5.3.10-1.mga1 php-doc-5.3.10-1.mga1 php-dom-5.3.10-1.mga1 php-enchant-5.3.10-1.mga1 php-exif-5.3.10-1.mga1 php-fileinfo-5.3.10-1.mga1 php-filter-5.3.10-1.mga1 php-fpm-5.3.10-1.mga1 php-ftp-5.3.10-1.mga1 php-gd-5.3.10-1.mga1 php-gettext-5.3.10-1.mga1 php-gmp-5.3.10-1.mga1 php-hash-5.3.10-1.mga1 php-iconv-5.3.10-1.mga1 php-imap-5.3.10-1.mga1 php-ini-5.3.10-1.mga1 php-intl-5.3.10-1.mga1 php-json-5.3.10-1.mga1 php-ldap-5.3.10-1.mga1 php-mbstring-5.3.10-1.mga1 php-mcrypt-5.3.10-1.mga1 php-mssql-5.3.10-1.mga1 php-mysql-5.3.10-1.mga1 php-mysqli-5.3.10-1.mga1 php-mysqlnd-5.3.10-1.mga1 php-odbc-5.3.10-1.mga1 php-openssl-5.3.10-1.mga1 php-pcntl-5.3.10-1.mga1 php-pdo-5.3.10-1.mga1 php-pdo_dblib-5.3.10-1.mga1 php-pdo_mysql-5.3.10-1.mga1 php-pdo_odbc-5.3.10-1.mga1 php-pdo_pgsql-5.3.10-1.mga1 php-pdo_sqlite-5.3.10-1.mga1 php-pgsql-5.3.10-1.mga1 php-phar-5.3.10-1.mga1 php-posix-5.3.10-1.mga1 php-pspell-5.3.10-1.mga1 php-readline-5.3.10-1.mga1 php-recode-5.3.10-1.mga1 php-session-5.3.10-1.mga1 php-shmop-5.3.10-1.mga1 php-snmp-5.3.10-1.mga1 php-soap-5.3.10-1.mga1 php-sockets-5.3.10-1.mga1 php-sqlite3-5.3.10-1.mga1 php-sybase_ct-5.3.10-1.mga1 php-sysvmsg-5.3.10-1.mga1 php-sysvsem-5.3.10-1.mga1 php-sysvshm-5.3.10-1.mga1 php-tidy-5.3.10-1.mga1 php-tokenizer-5.3.10-1.mga1 php-wddx-5.3.10-1.mga1 php-xml-5.3.10-1.mga1 php-xmlreader-5.3.10-1.mga1 php-xmlrpc-5.3.10-1.mga1 php-xmlwriter-5.3.10-1.mga1 php-xsl-5.3.10-1.mga1 php-zip-5.3.10-1.mga1 php-zlib-5.3.10-1.mga1 from SRPMS: php-5.3.10-1.mga1.i586.rpm php-ini-5.3.10-1.mga1.i586.rpm
Please would somebody respond to comment 8 and comment 16 ...
(In reply to comment #21) > Please would somebody respond to comment 8 and comment 16 ... The list of other things that needs to be built is different with each PHP update. Sometimes nothing else needs to be rebuilt. I don't know how Oden @ MDV figures it out, but based on what Thomas said in Comment 10 and Comment 12, it looks like nothing else this time. That actually makes sense, as PHP 5.3.10 is just a small fix for a CVE introduced in 5.3.9. For times like this where we don't have guidance from Mandriva (beyond seeing what they rebuilt in Cooker), we could just test other things and make sure they still work, if you're really worried about it. At this point, I would say that the maintainer has given his opinion, backed by evidence, that nothing else needs rebuilt. The QA team can decide if it wants to just test the updated RPMs, or test for other things (like php-apc, php-eaccelerator, or anything else that was rebuilt in a previous PHP update) just to be sure in situations like this. I think that's the best we can do. Hope that helps.
reply to comment 8 and 16: Someone mentioned at the last time that mots of the php-packages need to be rebuilt. I took that advice seriously and spend a lot of time to rebuild them. But I have the feeling, it's not needed. We have updated cauldron to php-5.3.10 and nobody as complained, I have tested it in kolab with success and feel pretty comfortable, we will be OK. If anybody knows, which packages need to be rebuilt, I would be glad to do them.
Has anybody asked MDV?
As expected.. # php -m [eAccelerator] This build of "eAccelerator" was compiled for PHP version 5.3.9. Rebuild it for your PHP version (5.3.10) or download precompiled binaries. # php -i [eAccelerator] This build of "eAccelerator" was compiled for PHP version 5.3.9. Rebuild it for your PHP version (5.3.10) or download precompiled binaries. eAccelerator eAccelerator support => enabled Version => 0.9.6.1 Caching Enabled => false Optimizer Enabled => false Check mtime Enabled => false /var/log/httpd/error.log [Sun Feb 19 18:29:06 2012] [error] [client 192.168.1.60] PHP Warning: Division by zero in /var/www/php-eaccelerator/index.php on line 117, referer: http://mega/php-eaccelerator/index.php?sec=0 I get the impression we are still using guesswork with php updates which is not really a good idea for the stable Mageia 1 which is used on our own servers. It is the reason it was assigned back to maintainer originally.
I agree with Claire here. QA Team is not meant to find out this kind of side-effects of such an update, this is something the packagers must work out before handling the update to QA. If the maintainer is unsure, he can still ask on the mageia-dev mailing list. If the maintainer doesn't have the possibility to test specific cases (in my opinion a maintainer should always have a stale version of the distro somewhere for testing), he can still ask for help from QA team, but this requires listing what needs testing and not just submitting the package and waiting for QA to sort it out. @thomas: this it nothing personal against you, I'm personnally very glad you are the maintainer for php, but sometimes the process needs to be clarified so that we can work better in the future. Strictly speaking, this update is not ready for QA yet, as Claire showed when testing php-apc and php-eaccelerator after having warned 2 times that they might need a rebuild. This should have been checked. However, I think we can work together packager + QA for this update to define together what *is* a good PHP update. First thing being testing all packages depending on PHP and identified for each what triggers the need for a rebuild. For the previous PHP update I already advised to open a wiki page listing everything that must be done (for packagers and QA) for a PHP update, including how to handle the packages that need testing, and I still thing this is a good idea, that will help for PHP 5.3.11 :)
(In reply to comment #26) > First thing being testing all packages depending on PHP and > identified for each what triggers the need for a rebuild. Ouch, the list is huge! http://mageia.madb.org/package/list/application/0/source/1/t_search/php/page/1
I guess we need to re-build all packages that have a BuildRequires: php-devel I did rebuild php-eaccelarator and php-apc We should not have upgraded to 5.3.10. MDV didn't either. Maybe Funda can help since he did let this thing lose :) I am running out of time, I am traveling most of coming week.
(In reply to comment #28) > We should not have upgraded to 5.3.10. Why not? 5.3.9 introduced a major security breach, which 5.3.10 fixes.
(In reply to comment #28) > I guess we need to re-build all packages that have a BuildRequires: php-devel Nope. Not all php packages depend on a specific version... Just rebuild the ones that were done with the last php update, and we should be ok (atleast no bugs has been reported afaik on the last update)
CC: (none) => tmb
The php packages that do require a specific version of php, such as php-eaccelerator should have version specific requires to ensure it's obvious from urpmi which ones need to be rebuilt.
CC: (none) => davidwhodgins
I just rebuilt all packages we did rebuild at the last update: php-apc php-pear php-sasl php-suhosin php-xdebug
I'm not sure all of those required a rebuild as some were built to fix CVEs but it is a good starting point and something we can work with, thankyou. Perhaps you could try to find out more details before the next update Thomas. Was eaccelerator also rebuilt as that definitely had issues?
Sorry, just read comment 28, you did that one already.
rpm -q -i apache-mod_php|grep Source Group : System/Servers Source RPM: php-5.3.10-1.mga1.src.rpm Should the srpm apache-mod_php-5.3.8-0.1.mga1.src.rpm be deleted from Core Updates Testing? Is the following list of srpms complete ... php-5.3.10-1.mga1.src.rpm php-apc-3.1.9-0.7.mga1.src.rpm php-eaccelerator-0.9.6.1-6.3.mga1.src.rpm php-ini-5.3.10-1.mga1.src.rpm php-pear-1.9.4-0.2.mga1.src.rpm php-sasl-0.1.0-34.2.mga1.src.rpm php-suhosin-0.9.32.1-5.2.mga1.src.rpm php-xdebug-2.1.2-1.2.mga1.src.rpm Should the php update be held, to go toether with the apache update, since most of us are testing them both at the same time?
(In reply to comment #35) > rpm -q -i apache-mod_php|grep Source > Group : System/Servers Source RPM: > php-5.3.10-1.mga1.src.rpm > > Should the srpm apache-mod_php-5.3.8-0.1.mga1.src.rpm be deleted from > Core Updates Testing? Yes. > Is the following list of srpms complete ... > php-5.3.10-1.mga1.src.rpm > php-apc-3.1.9-0.7.mga1.src.rpm > php-eaccelerator-0.9.6.1-6.3.mga1.src.rpm > php-ini-5.3.10-1.mga1.src.rpm > php-pear-1.9.4-0.2.mga1.src.rpm > php-sasl-0.1.0-34.2.mga1.src.rpm > php-suhosin-0.9.32.1-5.2.mga1.src.rpm > php-xdebug-2.1.2-1.2.mga1.src.rpm Yes. At least right now :o) > Should the php update be held, to go toether with the apache update, > since most of us are testing them both at the same time? They should be tested together. They are separate advisories, so they won't be issued at the exact same time, but if either goes first, it should be Apache (even if it's by one minute) IMO. It's not a big issue though because, as you said, most of us are testing them at the same time.
x86_64 Confirmed php-xdebug produces stacktraces in /var/log/httpd/error_log Confirmed suhosin is working but with it's default settings it is overzealous and causing segfaults with things like wordpress. Created bug 4677 for this issue, it is not a regression. php-pear checked with bacula-web by browsing to localhost/bacula/bacula-web/test.php and also the script attached to bug 3895 ( attachment 1397 [details] ) php-eaccelerator checked, error message is now gone and after installing php-eaccelerator-admin accessing localhost/eaccelerator shows the admin page where it can be seen to be activated and working. (login: admin/eAccelerator) php-apc checked with it's admin package browsing to localhost/php-apc. Default password should first be changed in /var/www/php-apc/index.php Otherwise, tested with wordpress, phpmyadmin, zoneminder and mediawiki I haven't worked out how to test php-sasl other than installing it and checking logs but it is not a recursive require of any of our packages. Testing complete x86_64 for these packages.
Validating the update after completing same tests on i586. Could someone from the sysadmin team push the srpms php-5.3.10-1.mga1.src.rpm php-apc-3.1.9-0.7.mga1.src.rpm php-eaccelerator-0.9.6.1-6.3.mga1.src.rpm php-ini-5.3.10-1.mga1.src.rpm php-pear-1.9.4-0.2.mga1.src.rpm php-sasl-0.1.0-34.2.mga1.src.rpm php-suhosin-0.9.32.1-5.2.mga1.src.rpm php-xdebug-2.1.2-1.2.mga1.src.rpm from Core Updates Testing to Core updates and Delete the srpm apache-mod_php-5.3.8-0.1.mga1.src.rpm be deleted from Core Updates Testing. Advisory: Updated php packages fix security vulnerability: PHP before 5.3.9 computes hash values for form parameters without restricting the ability to trigger hash collisions predictably, which allows remote attackers to cause a denial of service (CPU consumption) by sending many crafted parameters (CVE-2011-4885). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4885 https://bugs.mageia.org/show_bug.cgi?id=4435
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
apache-mod_php-5.3.8-0.1.mga1.src.rpm deleted... Update pushed... This also closes: https://bugs.mageia.org/show_bug.cgi?id=4390
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED