Unaffected: >=5.5.16, >=~5.4.32, >=~5.3.29, >=~5.4.34, >=~5.4.35, >=~5.4.36, >=~5.4.37, >=~5.4.38 Unaffected: >=5.5.21, >=~5.4.37, >=~5.4.38, >=~5.4.39 Unaffected: >=5.5.18, >=~5.4.34, >=~5.3.29, >=~5.4.36, >=~5.4.37, >=~5.4.38, >=~5.4.39, >=~5.4.35 Now in tree we have stable 5.4.39,5.4.40 and 5.4.41. All of them are not affected but each run glsa-check shows it as affected. Reproducible: Always
For Versions: 5.4.41 5.5.25-r1 are going through stabilizaiton. Bug 549538 For the other versions GLSA is still pending and in the release stage. We do not mention UNSTABLE versions in GLSA, they are patched as best effort allows as they are considered testing.
But for 549538 - there is a different GLSA. 5.4.40 and 5.4.41 is stable, why glsa-check is complaining? gawriloff@falcon-cl3 ~ $ eix -I php [I] dev-lang/php Available versions: (5.4) 5.4.39 5.4.40 5.4.41 ~5.4.42 (5.5) [m]5.5.22 [m]5.5.23 [m]5.5.24 [m]5.5.25 [m]5.5.25-r1 [m]~5.5.26 (5.6) [m]~5.6.7 [m]~5.6.8 [m]5.6.9 [m]~5.6.10 (7.0) [M]~7.0.0_alpha1 [M]~7.0.0_alpha2 {apache2 bcmath berkdb bzip2 calendar cdb cgi cjk +cli crypt +ctype curl curlwrappers debug embed enchant exif +fileinfo +filter firebird flatfile fpm frontbase ftp gd gdbm gmp +hash +iconv imap inifile intl iodbc ipv6 +json kerberos ldap ldap-sasl libedit libmysqlclient mhash mssql mysql mysqli mysqlnd nls oci8-instant-client odbc +opcache pcntl pdo +phar +posix postgres qdbm readline recode selinux +session sharedmem +simplexml snmp soap sockets spell sqlite ssl sybase-ct systemd sysvipc threads tidy +tokenizer truetype unicode vpx wddx +xml xmlreader xmlrpc xmlwriter xpm xslt zip zlib} Installed versions: 5.4.41(5.4)(10:34:48 08.06.2015)(apache2 bcmath cli crypt ctype curl filter ftp gd hash iconv imap intl json ldap mhash mssql mysql mysqli odbc pcntl pdo phar posix postgres session sharedmem simplexml soap sockets sqlite ssl sysvipc tidy tokenizer truetype unicode xml xmlreader xmlrpc xmlwriter zip zlib -berkdb -bzip2 -calendar -cdb -cgi -cjk -curlwrappers -debug -embed -enchant -exif -fileinfo -firebird -flatfile -fpm -gdbm -gmp -inifile -iodbc -ipv6 -kerberos -ldap-sasl -libedit -mysqlnd -nls -oci8-instant-client -qdbm -readline -recode -selinux -snmp -spell -sybase-ct -systemd -threads -wddx -xpm -xslt) Homepage: http://php.net/ Description: The PHP language runtime engine: CLI, CGI, FPM/FastCGI, Apache2 and embed SAPIs gawriloff@falcon-cl3 ~ $ glsa-check -l affected [A] means this GLSA was marked as applied (injected), [U] means the system is not affected and [N] indicates that the system might be affected. 201408-11 [N] PHP: Multiple vulnerabilities ( dev-lang/php ) 201411-04 [N] PHP: Multiple vulnerabilities ( dev-lang/php ) 201503-03 [N] PHP: Multiple vulnerabilities ( dev-lang/php ) gawriloff@falcon-cl3 ~ $
This is because the three GLSAs lists GLSA 201408-11: Vulnerable: <5.5.16 GLSA 201411-04: Vulnerable: <5.5.18 GLSA 201503-03: Vulnerable: <5.5.21 as vulnerable. Thus, every version is marked as affected despite the mention of 5.4 versions in Unaffacted. So we should add the vulnerable 5.4 versions, probably with slots. The last time i checked, the GLSA XSD did not allow slots in the range specifier though.
We have dup of this at #550562 Also now we have the same with postgresql GLSA 201507-20: Vulnerable: <9.4.3 Unaffected: >=~9.0.21, >=~9.1.17, >=~9.2.12, >=~9.3.8, >=9.4.3 [I] dev-db/postgresql Available versions: (9.0) 9.0.21^t 9.0.22^t (9.1) 9.1.17^t 9.1.18^t (9.2) 9.2.12 9.2.13 (9.3) 9.3.8{tbz2} 9.3.9{tbz2} Installed versions: 9.3.9(9.3){tbz2}(10:20:19 16.07.2015)(nls pam readline ssl zlib -doc -kerberos -ldap -perl -pg_legacytimestamp -python -selinux -server -static-libs -tcl -threads -uuid -xml KERNEL="linux" LINGUAS="en ru -af -cs -de -es -fa -fr -hr -hu -it -ko -nb -pl -pt_BR -ro -sk -sl -sv -tr -zh_CN -zh_TW" PYTHON_SINGLE_TARGET="python2_7 -python3_3 -python3_4" PYTHON_TARGETS="python2_7 -python3_3 -python3_4")
Sorry for not fixing this faster. These false positives arise due to a limitation of the current GLSA format: We can't properly supply information about SLOTs in GLSAs and have to explicitly enumerate older versions to make glsa-check recognize them as unaffected. I have just added PHP versions up to 5.4.46 (which doesn't exist yet) to the mentioned PHP GLSAs, as well as few future versions of PostgreSQL to the PostgreSQL GLSA to work around this issue.
*** Bug 556208 has been marked as a duplicate of this bug. ***
Another false report? # glsa-check -ql affected 201507-20 [N] PostgreSQL: Multiple vulnerabilities ( dev-db/postgresql ) # emerge -pq postgresql [ebuild R ] dev-db/postgresql-9.3.12
