a new update is released, which fixes many buffer overflow issues in gd, mbstring, phar and xmlrpc
backports is also affected - do we need another bug for this, or can I put both in one bug?
Updated php packages fix security vulnerabilities: Several buffer overflows in the components GD, MBString, Phar and XMLRPC were discovered and fixed. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=2016-10166 https://bugs.php.net/bug.php?id=77269 https://bugs.php.net/bug.php?id=77270 https://bugs.php.net/bug.php?id=77370 https://bugs.php.net/bug.php?id=77371 https://bugs.php.net/bug.php?id=77381 https://bugs.php.net/bug.php?id=77382 https://bugs.php.net/bug.php?id=77385 https://bugs.php.net/bug.php?id=77394 https://bugs.php.net/bug.php?id=77418 https://bugs.php.net/bug.php?id=77247 https://bugs.php.net/bug.php?id=77242 https://bugs.php.net/bug.php?id=77380 ======================== Updated packages in core/updates_testing: ======================== php-ini-5.6.40-1.mga6 apache-mod_php-5.6.40-1.mga6 php-cli-5.6.40-1.mga6 php-cgi-5.6.40-1.mga6 libphp5_common5-5.6.40-1.mga6 php-devel-5.6.40-1.mga6 php-openssl-5.6.40-1.mga6 php-zlib-5.6.40-1.mga6 php-doc-5.6.40-1.mga6 php-bcmath-5.6.40-1.mga6 php-bz2-5.6.40-1.mga6 php-calendar-5.6.40-1.mga6 php-ctype-5.6.40-1.mga6 php-curl-5.6.40-1.mga6 php-dba-5.6.40-1.mga6 php-dom-5.6.40-1.mga6 php-enchant-5.6.40-1.mga6 php-exif-5.6.40-1.mga6 php-fileinfo-5.6.40-1.mga6 php-filter-5.6.40-1.mga6 php-ftp-5.6.40-1.mga6 php-gd-5.6.40-1.mga6 php-gettext-5.6.40-1.mga6 php-gmp-5.6.40-1.mga6 php-hash-5.6.40-1.mga6 php-iconv-5.6.40-1.mga6 php-imap-5.6.40-1.mga6 php-interbase-5.6.40-1.mga6 php-intl-5.6.40-1.mga6 php-json-5.6.40-1.mga6 php-ldap-5.6.40-1.mga6 php-mbstring-5.6.40-1.mga6 php-mcrypt-5.6.40-1.mga6 php-mssql-5.6.40-1.mga6 php-mysql-5.6.40-1.mga6 php-mysqli-5.6.40-1.mga6 php-mysqlnd-5.6.40-1.mga6 php-odbc-5.6.40-1.mga6 php-opcache-5.6.40-1.mga6 php-pcntl-5.6.40-1.mga6 php-pdo-5.6.40-1.mga6 php-pdo_dblib-5.6.40-1.mga6 php-pdo_firebird-5.6.40-1.mga6 php-pdo_mysql-5.6.40-1.mga6 php-pdo_odbc-5.6.40-1.mga6 php-pdo_pgsql-5.6.40-1.mga6 php-pdo_sqlite-5.6.40-1.mga6 php-pgsql-5.6.40-1.mga6 php-phar-5.6.40-1.mga6 php-posix-5.6.40-1.mga6 php-readline-5.6.40-1.mga6 php-recode-5.6.40-1.mga6 php-session-5.6.40-1.mga6 php-shmop-5.6.40-1.mga6 php-snmp-5.6.40-1.mga6 php-soap-5.6.40-1.mga6 php-sockets-5.6.40-1.mga6 php-sqlite3-5.6.40-1.mga6 php-sybase_ct-5.6.40-1.mga6 php-sysvmsg-5.6.40-1.mga6 php-sysvsem-5.6.40-1.mga6 php-sysvshm-5.6.40-1.mga6 php-tidy-5.6.40-1.mga6 php-tokenizer-5.6.40-1.mga6 php-xml-5.6.40-1.mga6 php-xmlreader-5.6.40-1.mga6 php-xmlrpc-5.6.40-1.mga6 php-xmlwriter-5.6.40-1.mga6 php-xsl-5.6.40-1.mga6 php-wddx-5.6.40-1.mga6 php-zip-5.6.40-1.mga6 php-fpm-5.6.40-1.mga6 phpdbg-5.6.40-1.mga6 php-debuginfo-5.6.40-1.mga6 Source RPMs: php-5.6.40-1.mga6.src.rpm For Backports: Updated php packages fix security vulnerabilities: Several buffer overflows in the components GD, MBString, Phar and XMLRPC were discovered and fixed. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=2016-10166 https://bugs.php.net/bug.php?id=77269 https://bugs.php.net/bug.php?id=77270 https://bugs.php.net/bug.php?id=77370 https://bugs.php.net/bug.php?id=77371 https://bugs.php.net/bug.php?id=77381 https://bugs.php.net/bug.php?id=77382 https://bugs.php.net/bug.php?id=77385 https://bugs.php.net/bug.php?id=77394 https://bugs.php.net/bug.php?id=77418 https://bugs.php.net/bug.php?id=77247 https://bugs.php.net/bug.php?id=77242 https://bugs.php.net/bug.php?id=77380 ======================== Updated packages in core/backports_testing: ======================== php-ini-7.2.14-1.mga6 apache-mod_php-7.2.14-1.mga6 php-cli-7.2.14-1.mga6 php-cgi-7.2.14-1.mga6 libphp_common7-7.2.14-1.mga6 php-devel-7.2.14-1.mga6 php-openssl-7.2.14-1.mga6 php-zlib-7.2.14-1.mga6 php-doc-7.2.14-1.mga6 php-bcmath-7.2.14-1.mga6 php-bz2-7.2.14-1.mga6 php-calendar-7.2.14-1.mga6 php-ctype-7.2.14-1.mga6 php-curl-7.2.14-1.mga6 php-dba-7.2.14-1.mga6 php-dom-7.2.14-1.mga6 php-enchant-7.2.14-1.mga6 php-exif-7.2.14-1.mga6 php-fileinfo-7.2.14-1.mga6 php-filter-7.2.14-1.mga6 php-ftp-7.2.14-1.mga6 php-gd-7.2.14-1.mga6 php-gettext-7.2.14-1.mga6 php-gmp-7.2.14-1.mga6 php-hash-7.2.14-1.mga6 php-iconv-7.2.14-1.mga6 php-imap-7.2.14-1.mga6 php-interbase-7.2.14-1.mga6 php-intl-7.2.14-1.mga6 php-json-7.2.14-1.mga6 php-ldap-7.2.14-1.mga6 php-mbstring-7.2.14-1.mga6 php-mysqli-7.2.14-1.mga6 php-mysqlnd-7.2.14-1.mga6 php-odbc-7.2.14-1.mga6 php-opcache-7.2.14-1.mga6 php-pcntl-7.2.14-1.mga6 php-pdo-7.2.14-1.mga6 php-pdo_dblib-7.2.14-1.mga6 php-pdo_firebird-7.2.14-1.mga6 php-pdo_mysql-7.2.14-1.mga6 php-pdo_odbc-7.2.14-1.mga6 php-pdo_pgsql-7.2.14-1.mga6 php-pdo_sqlite-7.2.14-1.mga6 php-pgsql-7.2.14-1.mga6 php-phar-7.2.14-1.mga6 php-posix-7.2.14-1.mga6 php-readline-7.2.14-1.mga6 php-recode-7.2.14-1.mga6 php-session-7.2.14-1.mga6 php-shmop-7.2.14-1.mga6 php-snmp-7.2.14-1.mga6 php-soap-7.2.14-1.mga6 php-sockets-7.2.14-1.mga6 php-sqlite3-7.2.14-1.mga6 php-sysvmsg-7.2.14-1.mga6 php-sysvsem-7.2.14-1.mga6 php-sysvshm-7.2.14-1.mga6 php-tidy-7.2.14-1.mga6 php-tokenizer-7.2.14-1.mga6 php-xml-7.2.14-1.mga6 php-xmlreader-7.2.14-1.mga6 php-xmlrpc-7.2.14-1.mga6 php-xmlwriter-7.2.14-1.mga6 php-xsl-7.2.14-1.mga6 php-wddx-7.2.14-1.mga6 php-zip-7.2.14-1.mga6 php-fpm-7.2.14-1.mga6 phpdbg-7.2.14-1.mga6 php-debuginfo-7.2.14-1.mga6 Source RPMs: php-7.2.14-1.mga6.src.rpm
Assignee: mageia => qa-bugs
Summary: new version 5.6.40 fixes some bugs => php: new version 5.6.40 fixes some bugs
CVE-2016-10166 Mageia 6, x86_64 Did not really know how to handle this because version 7.2 was already installed. Went ahead anyway with backports-testing. Checked the vulnerabilities and test cases. potential unsigned underflow CVE-2016-10167 DOS vulnerability in gdImageCreateFromGd2Ctx() CVE-2016-10168 Signed Integer Overflow gd_io.c ------------------------------------------------- Before update - version 7.2.13-2 Attempting to match exploit files with CVEs: CVE-2016-10167 https://bugs.php.net/bug.php?id=77269 Test script: <?php $img = imagecreate(pow(2, 27), 0x01); var_dump(imagescale($img, 0x01, 0x01, 20)); echo "Execution continues!\n"; $ php test_1.php resource(5) of type (gd) Execution continues! < No crash implies that the hole has been plugged > Out of bounds write: https://bugs.php.net/bug.php?id=77270 <?php $img1 = imagecreatetruecolor(0xfff, 0xfff); $img2 = imagecreate(0xfff, 0xfff); imagecolorallocate($img2, 0, 0, 0); imagesetpixel($img2, 0, 0, 255); imagecolormatch($img1, $img2); $ php test_2.php *** Error in `php': munmap_chunk(): invalid pointer: 0x0000000001efb150 *** [...] Aborted (core dumped) < this looks like a failure > https://bugs.php.net/bug.php?id=77270 Other tests are posted but no links to the PoC data. $ php -r 'var_dump(mb_split(" \xfd",""));' array(1) { [0]=> string(0) "" } < upstream this did not crash although it was expected to - same here > https://bugs.php.net/bug.php?id=77371 $ php -r 'var_dump(mb_ereg("()0\xfc00000\xfc00000\xfc00000\xfc",""));' bool(false) < upstream reports an abort using the ASAN framework > https://bugs.php.net/bug.php?id=77381 $ php -r 'var_dump(mb_ereg("000||0\xfa","0"));' int(1) < similarly - upstream test aborted > https://bugs.php.net/bug.php?id=77382 $ php -r 'var_dump(mb_ereg("(?i)000000000000000000000\xf0",""));' bool(false) < aborted upstream > https://bugs.php.net/bug.php?id=77385 $ php -r 'var_dump(mb_ereg("0000\\"."\xf5","0"));' bool(false) < upstream abort > https://bugs.php.net/bug.php?id=77394 $ php -r 'var_dump(mb_ereg("(?i)FFF00000000000000000\xfd",""));' bool(false) < abort upstream > https://bugs.php.net/bug.php?id=77418 $ php -r 'mb_regex_encoding("UTF-32");var_dump(mb_split("\x00\x00\x00\x5c\x00\x00\x00B","000000000000000000000000000000"));' array(1) { [0]=> string(30) "000000000000000000000000000000" } < upstream abort > https://bugs.php.net/bug.php?id=77247 https://github.com/whiteHat001/FUZZ_POC/blob/master/poc.phar $ USE_ZEND_ALLOC=0 php -r "var_dump(new Phar(file_get_contents('poc.phar'),0,'test.phar'));" PHP Fatal error: Uncaught UnexpectedValueException: Cannot create phar 'DDDDDDDDDDDDD/.DDDDDDDDDDDdDDDDD_DDDDDD', file extension (or combination) not recognised or the directory does not exist in Command line code:1 Stack trace: #0 Command line code(1): Phar->__construct('DDDDDDDDDDDDD/....', 0, 'test.phar') #1 {main} thrown in Command line code on line 1 < heap buffer overflow under asan leading to an abort > https://bugs.php.net/bug.php?id=77242 $ $a=xmlrpc_decode(base64_decode("PD94bWwgdmVyc2lvbmVuY29kaW5nPSJJU084ODU5NyKkpKSkpKSkpKSkpKSkpKSkpKSkpKSk")); bash: syntax error near unexpected token `base64_decode' < test run incorrectly - see later remark > Global out of bounds buffer read https://bugs.php.net/bug.php?id=77380 $ $a=xmlrpc_decode(base64_decode("PGJhc2U2ND7CkzwvYmFzZTY0Pgo=")); bash: syntax error near unexpected token `base64_decode' < test run incorrectly - see later remark > ------------------------------------------------------------------- Updated to 7.2.14-1 from backports-testing $ php test_1.php resource(5) of type (gd) Execution continues! < good > $ php test_2.php [...] Aborted (core dumped) < not good > In fact all the tests returned the same results which means that some of the vulnerabilities had already been patched. However, the penny dropped for the last two; wrapped the code in php and returned something different... $ php testa_1.php expat reports error code 4 description: not well-formed (invalid token) line: 1 column: 32 byte index: 32 total bytes: 0 data beginning 10 before byte index: "ISO88597"���������������������� < looks like a good result > $ php testa_2.php $ < no global out-of-bounds buffer read, so it is good > End of part 1 - to be continued.
CC: (none) => tarazed25
@Len: did you miss to update php-gd? You should have php-gd-7.2.14-1.mga6. Running test2 did not give me a core dump.
@Marc: Yes. It is there. $ rpm -qa | grep php-gd php-gd-7.2.14-1.mga6 A re-run gives the same result. Maybe there is something else missing here. I have lib64gd3-2.2.5-2.1.mga6 gd-utils-2.2.5-2.1.mga6 Probably irrelevant. $ cat test_2.php <?php $img1 = imagecreatetruecolor(0xfff, 0xfff); $img2 = imagecreate(0xfff, 0xfff); imagecolorallocate($img2, 0, 0, 0); imagesetpixel($img2, 0, 0, 255); imagecolormatch($img1, $img2); The backtrace mentions zend* functions Running $ valgrind --leak-check=full php test_2.php appears to implicate zend* functions in several memory leaks. zend_startup_module_ex, zend_hash_apply, zend_startup_modules then php_module_startup. Again, this stuff may be irrelevant.
Continuing thread from comment 5: $ strace php test_2.php 2> trace2$ cat trace2 | grep gd stat("/etc/php.d/23_gd.ini", {st_mode=S_IFREG|0644, st_size=227, ...}) = 0 open("/etc/php.d/23_gd.ini", O_RDONLY) = 3 open("/lib64/libgdbm.so.4", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/php/extensions/gd", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/php/extensions/gd.so", O_RDONLY|O_CLOEXEC) = 3 open("/lib64/libgd.so.3", O_RDONLY|O_CLOEXEC) = 3 $ rpm -qa | grep gdbm lib64gdbm4-1.12-1.mga6 lib64gdbm-devel-1.12-1.mga6 libgdbm4-1.12-1.mga6
Moved the contents of the php testing directory to another folder on this machine and tried the test_2.php file again. This time there was no abort. There is definitely something strange going on here; the test runs without an abort if the directory is sited anywhere else on this system, on the /home disk, the /data disk or in /tmp on the system disk. Since the test runs without an abort anywhere else, the result is good. I shall just have to live with whatever gremlins are affecting my system here and perform double-checks on everything in future.
@Len you're right. I can see the problem with valgrind (thanks!). Patched libgd. It now compiles and will be "libgd-2.2.5-2.2.mga6" in updates_testing. With this lib, the test should succeed! Sorry, my fault. Thanks for the good tests and all the work you've done!
Thanks Marc - it does indeed work now. And without all your hard work and that of other packagers we in QA would not have a job.
Installed and tested the PHP 7.2.14 without issues. Tested with various large (e.g. wordpress, drupal, roundcubemail) and small scripts, using HTTP(S) and CLI. Also tested the various PoC. Note that I did not test and no longer use the PHP 5.6 version. System: Mageia 6, x86_64, Intel CPU. $ uname -a Linux marte 4.14.89-desktop-1.mga6 #1 SMP Mon Dec 17 13:14:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux $ php --version PHP 7.2.14 (cli) (built: Jan 11 2019 09:51:36) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies with Xdebug v2.6.1, Copyright (c) 2002-2018, by Derick Rethans $ rpm -qa | grep 7.2.14 | sort -u apache-mod_php-7.2.14-1.mga6 lib64php_common7-7.2.14-1.mga6 php-bz2-7.2.14-1.mga6 php-cli-7.2.14-1.mga6 php-ctype-7.2.14-1.mga6 php-curl-7.2.14-1.mga6 php-dom-7.2.14-1.mga6 php-fileinfo-7.2.14-1.mga6 php-filter-7.2.14-1.mga6 php-ftp-7.2.14-1.mga6 php-gd-7.2.14-1.mga6 php-gettext-7.2.14-1.mga6 php-hash-7.2.14-1.mga6 php-iconv-7.2.14-1.mga6 php-imap-7.2.14-1.mga6 php-ini-7.2.14-1.mga6 php-intl-7.2.14-1.mga6 php-json-7.2.14-1.mga6 php-ldap-7.2.14-1.mga6 php-mbstring-7.2.14-1.mga6 php-mysqli-7.2.14-1.mga6 php-mysqlnd-7.2.14-1.mga6 php-openssl-7.2.14-1.mga6 php-pdo-7.2.14-1.mga6 php-pdo_mysql-7.2.14-1.mga6 php-pdo_pgsql-7.2.14-1.mga6 php-pdo_sqlite-7.2.14-1.mga6 php-pgsql-7.2.14-1.mga6 php-phar-7.2.14-1.mga6 php-posix-7.2.14-1.mga6 php-session-7.2.14-1.mga6 php-sysvsem-7.2.14-1.mga6 php-sysvshm-7.2.14-1.mga6 php-tokenizer-7.2.14-1.mga6 php-xml-7.2.14-1.mga6 php-xmlreader-7.2.14-1.mga6 php-xmlrpc-7.2.14-1.mga6 php-xmlwriter-7.2.14-1.mga6 php-zip-7.2.14-1.mga6 php-zlib-7.2.14-1.mga6 $ $ cat test1.php <?php $img = imagecreate(pow(2, 27), 0x01); var_dump(imagescale($img, 0x01, 0x01, 20)); echo "Execution continues!\n"; $ php test1.php resource(5) of type (gd) Execution continues! $ # <OK>. $ $ cat test2.php <?php $img1 = imagecreatetruecolor(0xfff, 0xfff); $img2 = imagecreate(0xfff, 0xfff); imagecolorallocate($img2, 0, 0, 0); imagesetpixel($img2, 0, 0, 255); imagecolormatch($img1, $img2); $ php test2.php $ # <OK>. $ $ php -r 'var_dump(mb_split(" \xfd",""));' array(1) { [0]=> string(0) "" } $ # <OK>. $ $ php -r 'var_dump(mb_ereg("000||0\xfa","0"));' int(1) $ # <OK>. $ $ php -r 'var_dump(mb_split("(?i)000000000000000000000\xf0",""));' array(1) { [0]=> string(0) "" } $ # <OK> $ $ php -r 'var_dump(mb_ereg("0000\\"."\xf5","0"));' bool(false) $ # <OK> $ $ php -r 'var_dump(mb_ereg("(?i)FFF00000000000000000\xfd",""));' bool(false) $ # <OK> $ $ php -r 'mb_regex_encoding("UTF-32");var_dump(mb_split("\x00\x00\x00\x5c\x00\x00\x00B","000000000000000000000000000000"));' array(1) { [0]=> string(30) "000000000000000000000000000000" } $ # <OK> $ $ php -r '$a=xmlrpc_decode(base64_decode("PGJhc2U2ND7CkzwvYmFzZTY0Pgo="));' $ # <OK> $ $ php -r '$a=xmlrpc_decode(base64_decode("PD94bWwgdmVyc2lvbmVuY29kaW5nPSJJU084ODU5NyKkpKSkpKSkpKSkpKSkpKSkpKSkpKSk"));' expat reports error code 4 description: not well-formed (invalid token) line: 1 column: 32 byte index: 32 total bytes: 0 data beginning 10 before byte index: "ISO88597"���������������������� $ # <OK> $
CC: (none) => mageia
Just to be clear when pushing this, the SRPMS for this bug are: php-5.6.40-1.mga6.src.rpm libgd-2.2.5-2.2.mga6.src.rpm The backport needs its own bug.
It looks like libgd also needs: https://github.com/libgd/libgd/commit/c3cf674cb444696a36f720f785878b41225af063 according to: https://bugs.php.net/bug.php?id=77269
Moved to another system, which had a mixture of 5.6.38 and 5.6.39 packages. Normalized the system to 5.6.39-1. Ran the earlier tests with the same results. Updated from core updates testing - 72 packages. Added Marc's latest version of libgd3. All the PoC tests returned results matching the earlier updated backports tests. The only test which gives cause for concern is: $ USE_ZEND_ALLOC=0 php -r "var_dump(new Phar(file_get_contents('poc.phar'),0,'test.phar'));" PHP Fatal error: Uncaught exception 'UnexpectedValueException' with message 'Cannot create phar 'DDDDDDDDDDDDD/.DDDDDDDDDDDdDDDDD_DDDDDD', file extension (or combination) not recognised or the directory does not exist' in Command line code:1 Stack trace: #0 Command line code(1): Phar->__construct('DDDDDDDDDDDDD/....', 0, 'test.phar') #1 {main} thrown in Command line code on line 1 This is the same as before the update. ------------------------------------------------------------------------------- Aside from that last reservation, the thorough tests by PC LX show that php 7.2 works in the field so should receive a 64-bit OK when/if the bugs are split. As I am not a php user a simple utility test shall have to suffice for php 5.6. Restarted apache. $ php -S localhost:8000 -t php PHP 5.6.33 Development Server started at Mon Mar 12 11:50:42 2018 Listening on http://localhost:8000 Document root is /home/lcl/dev/php Press Ctrl-C to quit. In browser: localhost:8000/create-png.php --- < blue square on a black background > localhost:8000/sample.php --- < Prints the message contained in the sample file > php 5.6 also good for 64-bits.
@David: that patch is wired. At least it is not critical. It can be droped for now. @All: I'll clone this bug so we have one for 5.6.40 and one for 7.2.14
Blocks: (none) => 24176
MGA6-32 MATE on IBM Thinkpad R50e Trying to install the 5.6.40 on this laptop which has no previous php installed. Selecting the first item in MCC brings on: Sorry, het volgende pakket is niet selecteerbaar: (the package is not selectable) - apache-mod_php-5.6.40-1.mga6.i586 (vanwege onvoldane php-timezonedb[>= 3:2012.3] : unfulfilled php-timezone)
CC: (none) => herman.viaene
@Herman: comment 15. That is odd. The whole set installed cleanly both before and after the updates here and 'rpm -qa | grep php-timezone' returns no information so if that is a package it is not needed here.
Whiteboard: (none) => MGA6-64-OK
Re comment 16. I beg your pardon; that was the case for version 7.2. Checking the system containing version 5.6 shows that the php-timezonedb package was installed. It is not in the list for 5.6 - possibly already present here or pulled in as a dependency. I shall try to check that on another system.
we dropped php-timezone, since we provide this information by the system. Timezone is only needed for windows systems which have no systemwide. For 5.6.x we kept the old behaviour, php-timezonedb is present in the core packages and was not updated.
Thanks Marc. @Herman - just install php-timezonedb then and try the update. For some reason I had already installed it on my systems.
Keywords: (none) => advisory, validated_updateCC: (none) => lewyssmith, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2019-0042.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
This isn't fully fixed as the libgd issues weren't patched in our libgd package. Remember in the future whenever the PHP ChangeLog references GD, unless the issue only affected PHP's bundled issue, we need to patch libgd as well. The same is true for the zip extension and libzip, the fileinfo extension and the file package, pcre, mbstring, and probably other things, but most notably (historically) libgd and libzip.
Also, Comment 11 listed libgd as one of the SRPMS for this update, and it wasn't pushed.
Resolution: FIXED => (none)Status: RESOLVED => REOPENED
libgd issues moved to bug 24336.
Depends on: (none) => 24336CC: (none) => luigiwalser
Depends on: (none) => 24338
CC: lewyssmith => (none)
As the update for this bug has already been pushed, removing the keywords advisory, validated_update for now to ensure this bug report doesn't cause problems pushing updates.
CC: (none) => davidwhodgins
Keywords: advisory, validated_update => (none)
As bug 24338 has been closed, closing this bug now too.
Keywords: (none) => advisory, validated_updateStatus: REOPENED => RESOLVEDResolution: (none) => FIXED
It's not closed.
Oops. Sorry, misread the bug number in comment 23.
can we get this one out? Did I miss sth.? I don't expect any other result from i586 builds than for the 64bit build.
Well, php went out in: https://advisories.mageia.org/MGASA-2019-0042.html php 7 went out in: https://bugs.mageia.org/show_bug.cgi?id=24176#c12 libgd went out in: https://advisories.mageia.org/MGASA-2019-0073.html So that leaves: https://bugs.mageia.org/show_bug.cgi?id=24338 But since that has it's own bug...
Resolution: (none) => FIXEDCC: (none) => tmbStatus: REOPENED => RESOLVED