PHP 5.6.39 is expected to be released today, fixing CVE-2018-19518: https://www.openwall.com/lists/oss-security/2018/12/05/2
the last update before it is dropped. when do we push php 7.2 from backports to updates? after final support is dropped, or do we just leave it "unsupported"
CC: (none) => mageia
I don't know that we can reasonably do either. Aren't there some other distros still supported with 5.x that we could steal backported patches from in the future? It certainly would be irresponsible to leave it completely unsupported (though I obviously understand it becomes much more difficult to continue to support it), but 7.x is a huge transition that breaks lots of things, and those things you want to limit to distro upgrades. Every PHP-related package would have to be updated or obsoleted, and plus users may well be (and probably are) still running some non-packaged webapps that aren't 7.x compatible.
yeah I know that. Our fault was to deliver mga 6 without php7. I can still have a look for changes and try to adapt them. But php develeopers have clearly stated they will only push major security fixes and declare "php 5" as dead. Almost all official webhosters switch their php version to 7. For me an updated version in current release was always better than our decision to do it only on new releases. If the update went wrong, I was able to use the older version build for the current release. But if I've updated the whole server (desktop) in most cases I was not able to use the packages from the older mageia version. So I prefer to have newer versions in current releases due to downgrade possibility.
I agree that we should have shipped with PHP 7. We initially decided not to because we didn't have time (and some software still wasn't ready) to update everything for PHP 7 in time for the release, but then the release ended up getting significantly delayed and we had plenty of time that we could have changed it. We can't go back in time and fix that now.
what a pitty. we should better spend our time creating a time maschine :D Ok, so for now we release 5.6.39, when ready. mga7 is planned (hopefully it will) before fosdem (in february), so the support for mga6 is till ~september 2019. And we have php 7 in backports. still a long time without official security support which ends on 31 Dec 2018.
Assignee: php => mageia
Suggested advisory: ======================== Updated php packages fix security vulnerabilities: Bypassing disabled exec functions in PHP via imap_open (CVE-2018-19518). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19518 ======================== Updated packages in core/updates_testing: ======================== php-ini-5.6.39-1.mga6 apache-mod_php-5.6.39-1.mga6 php-cli-5.6.39-1.mga6 php-cgi-5.6.39-1.mga6 libphp5_common5-5.6.39-1.mga6 php-devel-5.6.39-1.mga6 php-openssl-5.6.39-1.mga6 php-zlib-5.6.39-1.mga6 php-doc-5.6.39-1.mga6.noarch php-bcmath-5.6.39-1.mga6 php-bz2-5.6.39-1.mga6 php-calendar-5.6.39-1.mga6 php-ctype-5.6.39-1.mga6 php-curl-5.6.39-1.mga6 php-dba-5.6.39-1.mga6 php-dom-5.6.39-1.mga6 php-enchant-5.6.39-1.mga6 php-exif-5.6.39-1.mga6 php-fileinfo-5.6.39-1.mga6 php-filter-5.6.39-1.mga6 php-ftp-5.6.39-1.mga6 php-gd-5.6.39-1.mga6 php-gettext-5.6.39-1.mga6 php-gmp-5.6.39-1.mga6 php-hash-5.6.39-1.mga6 php-iconv-5.6.39-1.mga6 php-imap-5.6.39-1.mga6 php-interbase-5.6.39-1.mga6 php-intl-5.6.39-1.mga6 php-json-5.6.39-1.mga6 php-ldap-5.6.39-1.mga6 php-mbstring-5.6.39-1.mga6 php-mcrypt-5.6.39-1.mga6 php-mssql-5.6.39-1.mga6 php-mysql-5.6.39-1.mga6 php-mysqli-5.6.39-1.mga6 php-mysqlnd-5.6.39-1.mga6 php-odbc-5.6.39-1.mga6 php-opcache-5.6.39-1.mga6 php-pcntl-5.6.39-1.mga6 php-pdo-5.6.39-1.mga6 php-pdo_dblib-5.6.39-1.mga6 php-pdo_firebird-5.6.39-1.mga6 php-pdo_mysql-5.6.39-1.mga6 php-pdo_odbc-5.6.39-1.mga6 php-pdo_pgsql-5.6.39-1.mga6 php-pdo_sqlite-5.6.39-1.mga6 php-pgsql-5.6.39-1.mga6 php-phar-5.6.39-1.mga6 php-posix-5.6.39-1.mga6 php-readline-5.6.39-1.mga6 php-recode-5.6.39-1.mga6 php-session-5.6.39-1.mga6 php-shmop-5.6.39-1.mga6 php-snmp-5.6.39-1.mga6 php-soap-5.6.39-1.mga6 php-sockets-5.6.39-1.mga6 php-sqlite3-5.6.39-1.mga6 php-sybase_ct-5.6.39-1.mga6 php-sysvmsg-5.6.39-1.mga6 php-sysvsem-5.6.39-1.mga6 php-sysvshm-5.6.39-1.mga6 php-tidy-5.6.39-1.mga6 php-tokenizer-5.6.39-1.mga6 php-xml-5.6.39-1.mga6 php-xmlreader-5.6.39-1.mga6 php-xmlrpc-5.6.39-1.mga6 php-xmlwriter-5.6.39-1.mga6 php-xsl-5.6.39-1.mga6 php-wddx-5.6.39-1.mga6 php-zip-5.6.39-1.mga6 php-fpm-5.6.39-1.mga6 phpdbg-5.6.39-1.mga6 php-debuginfo-5.6.39-1.mga6 Source RPMs: php-5.6.39-1.mga6.src.rpm
QA Contact: security => qa-bugs
There is also a new php 7.2.13 in backports_testing for mga6 which fixes the same issue as reported above.
CVE: (none) => CVE-2018-19518
Assignee: mageia => qa-bugs
MGA6-32 MATE on IBM Thinkpad R50e When I select as first in the list apache-mod_php, then it draws in the whole list of php pakages in version 7.2.13-1. That seems to jump the whole 5.6.39 edition????
CC: (none) => herman.viaene
If you have enabled both backports and updates, it will select the latest version available.
@all: found a bug in my last commit for the php.ini (php7) which was pushed to noarch. since we have 2 paths inside this file, it is arch dependend. fixed in release 2
(In reply to Marc Krämer from comment #10) > @all: found a bug in my last commit for the php.ini (php7) which was pushed > to noarch. since we have 2 paths inside this file, it is arch dependend. > fixed in release 2 Please create a bug report for testing PHP7 in backports. I will make nextcloud backport depend on it. https://bugs.mageia.org/show_bug.cgi?id=23998
CC: (none) => lists.jjorge
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=23999
@ Marc Comment 9: You were right in that I had Core backports updates testing enabled. But I disabled it in MCC, refreshed all repos, but still all dependencies on 7.2.13-1 came up.
MGA6-32 MATE on IBM Thinkpad R50e Installed updates of 5.6.39 using QArepo and MCC - Updates to isolate from the 7.2.13-1 version, all installed cleanly Ref bug 23760 for testing: $ php -r 'phpinfo();' | more PHP Warning: phpinfo(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in Command line code on line 1 phpinfo() PHP Version => 5.6.39 System => Linux mach6.hviaene.thuis 4.14.78-desktop-1.mga6 #1 SMP Sun Oct 21 20:41:16 UTC 2018 i686 Build Date => Dec 6 2018 22:56:38 Configure Command => './configure' '--with-apxs2=/usr/bin/apxs' '--build=i586-mageia-linux-gn u' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir and a lot more $ php -S localhost:8000 index.php PHP 5.6.39 Development Server started at Thu Dec 13 09:57:57 2018 Listening on http://localhost:8000 Document root is /home/tester6/Documenten Press Ctrl-C to quit. pointing browser to localhost:8000 displays a page of info. but subsequently pointing the browser to http://localhost:8000/create-png.php just keeps giving the info page. And yes, I have corrected the space error on the create-png.php script.
I think the "info" output at commandline may disturb generating the image (may be due to other tests). Maybe we can get a better test case, since image creation breaks easy. check /etc/php.d/05_date.ini the setting date.timezone = is set e.g. to 'Europe/Berlin'
Making a slight variation on the test gives a good result: starting the server without further parameters: $ php -S localhost:8000 PHP 5.6.39 Development Server started at Fri Dec 14 10:58:35 2018 Listening on http://localhost:8000 Document root is /home/tester6/Documenten Press Ctrl-C to quit. Then pointing the browser at http://localhost:8000/create-png.php creates the file one.png and displays the expected blue square in the browser and at the CLI the string: [Fri Dec 14 10:58:51 2018] 127.0.0.1:59036 [200]: /create-png.php And to Comment 14: there isn't such a file in /etc/php.d, neither none with "date" in its name.
Whiteboard: (none) => MGA6-32-OK
sorry in 5.6.x I still have this setting in main php.ini - in php 7.x it has moved to /etc/php.d/05_date.ini
Too late, I have already installed the 7.2.13 version on the testing laptop.
Given the complications Herman had with PHP version 7 mix, I just have 5.6.38-1 so will try this update for x64.
CC: (none) => lewyssmith
Keywords: (none) => advisory
5.6.39 is on the updates_testing mirrors: http://ftp.acc.umu.se/mirror/mageia/distrib/6/x86_64/media/core/updates_testing/ Please test the right version!
Testing M6 x64 AFTER update (from 5.6.38-1). With PHP already installed & working for several applications, I updated: - apache-mod_php-5.6.39-1.mga6.x86_64 - lib64php5_common5-5.6.39-1.mga6.x86_64 - php-bcmath-5.6.39-1.mga6.x86_64 - php-bz2-5.6.39-1.mga6.x86_64 - php-cli-5.6.39-1.mga6.x86_64 - php-ctype-5.6.39-1.mga6.x86_64 - php-dom-5.6.39-1.mga6.x86_64 - php-filter-5.6.39-1.mga6.x86_64 - php-ftp-5.6.39-1.mga6.x86_64 - php-gd-5.6.39-1.mga6.x86_64 - php-gettext-5.6.39-1.mga6.x86_64 - php-hash-5.6.39-1.mga6.x86_64 - php-iconv-5.6.39-1.mga6.x86_64 - php-ini-5.6.39-1.mga6.x86_64 - php-intl-5.6.39-1.mga6.x86_64 - php-json-5.6.39-1.mga6.x86_64 - php-ldap-5.6.39-1.mga6.x86_64 - php-mbstring-5.6.39-1.mga6.x86_64 - php-mcrypt-5.6.39-1.mga6.x86_64 - php-mysql-5.6.39-1.mga6.x86_64 - php-mysqli-5.6.39-1.mga6.x86_64 - php-mysqlnd-5.6.39-1.mga6.x86_64 - php-openssl-5.6.39-1.mga6.x86_64 - php-pdo-5.6.39-1.mga6.x86_64 - php-pdo_mysql-5.6.39-1.mga6.x86_64 - php-pgsql-5.6.39-1.mga6.x86_64 - php-posix-5.6.39-1.mga6.x86_64 - php-session-5.6.39-1.mga6.x86_64 - php-snmp-5.6.39-1.mga6.x86_64 - php-sockets-5.6.39-1.mga6.x86_64 - php-sysvsem-5.6.39-1.mga6.x86_64 - php-sysvshm-5.6.39-1.mga6.x86_64 - php-tokenizer-5.6.39-1.mga6.x86_64 - php-xml-5.6.39-1.mga6.x86_64 - php-xmlreader-5.6.39-1.mga6.x86_64 - php-xmlwriter-5.6.39-1.mga6.x86_64 - php-zip-5.6.39-1.mga6.x86_64 - php-zlib-5.6.39-1.mga6.x86_64 The update list showed additionally several MySQL related pkgs which could not be selected; and after applying the updates above, disappeared from the list. Played with PHPpgadmin, PHPmyadmin, MediaWiki, Bugzilla; which I am sure are driven by PHP. No problems. OKing, validating.
Whiteboard: MGA6-32-OK => MGA6-32-OK MGA6-64-OKKeywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0484.html
Status: NEW => RESOLVEDResolution: (none) => FIXED