managing security updates on some web servers I found that glsa-check encourages me doing this strange downgrade: Checking GLSA 200710-02 The following updates will be performed for this GLSA: dev-lang/php-5.2.5-r1 (5.2.6-r7) merging data from these three points: [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4887 [2] http://secunia.com/advisories/30048/ [3] php-5.2.6-r7.ebuild states itself stable for amd64 platforms could it be that glsa-check (gentoolkit-0.2.3-r1) might fail somewhere in versioning handling ?
Created attachment 165703 [details] $(emerge --info) output
This does not seem to be an error in the GLSA itself, it specifies: <package name="dev-lang/php" auto="yes" arch="*"> <unaffected range="ge">5.2.4_p20070914-r2</unaffected> <vulnerable range="lt">5.2.4_p20070914-r2</vulnerable> </package> I'm cc'ing portage-utils. Do you have some input on this?
> I'm cc'ing portage-utils. Do you have some input on this? so from my understanding it is just an "outdated" (for some reasons) glsa metadata xml file?
I'd say the XML is ok. I have no clue why glsa-check would want to downgrade. If you use eix, can you give me the output of eix dev-lang/php ?
(In reply to comment #2) > This does not seem to be an error in the GLSA itself, it specifies: .. > I'm cc'ing portage-utils. Do you have some input on this? I think you meant to CC: tools-portage@ (aka genone)
Correct, sorry.
(In reply to comment #4) > If you use eix, can you give me the output of eix dev-lang/php ? here is eix's output. as you can see I have two php versions installed. Could this multiple versioning setup be the culprit of this strange glsa-check behaviour? eva47 ~ # eix dev-lang/php [I] dev-lang/php Available versions: (4) *4.3.11-r5[1] 4.4.3-r1[1] 4.4.4-r4[1] 4.4.7[1] (5) 5.0.5-r5[1] 5.1.4-r6[1] 5.2.5-r1 5.2.6-r6 5.2.6-r7 {adabas apache2 bcmath berkdb birdstep bzip2 calendar cdb cgi cjk cli concurrentmodphp crypt ctype curl curlwrappers db2 dbase dbmaker dbx debug discard-path doc empress empress-bcs esoob exif expat fastbuild fdftk filepro filter firebird flatfile force-cgi-redirect frontbase ftp gd gd-external gdbm gmp hash hyperwave-api iconv imap informix inifile interbase iodbc ipv6 java-external java-internal json kerberos kolab ldap ldap-sasl libedit mcal mcve memlimit mhash ming mnogosearch msql mssql mysql mysqli ncurses nls oci8 oci8-instant-client odbc oracle7 overload pcntl pcre pdo pdo-external pfpro pic posix postgres qdbm readline recode reflection sapdb session sharedext sharedmem simplexml snmp soap sockets solid spell spl sqlite ssl suhosin sybase sybase-ct sysvipc threads tidy tokenizer truetype unicode wddx xml xmlreader xmlrpc xmlwriter xpm xsl yaz zip zip-external zlib} Installed versions: 4.4.7(4)(09:35:39 13/11/2007)(apache2 cgi cli crypt ctype curl expat fastbuild force-cgi-redirect ftp gd iconv mysql nls oci8-instant-client pcre pic posix session sockets ssl tokenizer truetype xml xsl zlib -adabas -bcmath -berkdb -birdstep -bzip2 -calendar -cdb -cjk -concurrentmodphp -db2 -dbase -dbmaker -dbx -debug -discard-path -doc -empress -empress-bcs -esoob -exif -fdftk -filepro -firebird -flatfile -frontbase -gd-external -gdbm -gmp -hyperwave-api -imap -informix -inifile -interbase -iodbc -ipv6 -java-external -java-internal -kerberos -ldap -libedit -mcal -mcve -memlimit -mhash -ming -mnogosearch -msql -mssql -ncurses -oci8 -odbc -oracle7 -overload -pcntl -pfpro -postgres -readline -recode -sapdb -sharedext -sharedmem -snmp -solid -spell -sqlite -suhosin -sybase -sybase-ct -sysvipc -threads -unicode -wddx -xmlrpc -xpm -yaz -zip) 5.2.6-r7(5)(19:43:59 17/09/2008)(bcmath berkdb bzip2 calendar cgi cli crypt ctype curl curlwrappers discard-path exif force-cgi-redirect gd gdbm iconv ipv6 json ldap mysql ncurses nls pcre pic posix readline reflection session simplexml sockets spl ssl tokenizer truetype unicode wddx xml xmlrpc xmlwriter xsl zip zlib -adabas -apache2 -birdstep -cdb -cjk -concurrentmodphp -db2 -dbase -dbmaker -debug -doc -empress -empress-bcs -esoob -fastbuild -fdftk -filter -firebird -flatfile -frontbase -ftp -gd-external -gmp -hash -imap -inifile -interbase -iodbc -java-external -kerberos -kolab -ldap-sasl -libedit -mcve -mhash -msql -mssql -mysqli -oci8 -oci8-instant-client -odbc -pcntl -pdo -postgres -qdbm -recode -sapdb -sharedext -sharedmem -snmp -soap -solid -spell -sqlite -suhosin -sybase -sybase-ct -sysvipc -threads -tidy -xmlreader -xpm -yaz -zip-external) Homepage: http://www.php.net/ Description: The PHP language runtime engine: CLI, CGI and Apache SAPIs. [1] /usr/overlay eva47 ~ #
luca: Yes, that is what is causing this. glsa-check will see that 4.X is affected by the GLSA, and tries to upgrade to the next higher unaffected version. Unfortunately, that version is in the 5 SLOT and causes a downgrade. I am not sure how we could solve this one without breaking other situations where upgrades to a higher SLOT are desired (thinking of webapps, for instance). But clearly, it should display that installed version which is causing the action.
(In reply to comment #8) > luca: Yes, that is what is causing this. glsa-check will see that 4.X is > affected by the GLSA, and tries to upgrade to the next higher unaffected > version. Unfortunately, that version is in the 5 SLOT and causes a downgrade. > > I am not sure how we could solve this one without breaking other situations > where upgrades to a higher SLOT are desired (thinking of webapps, for > instance). But clearly, it should display that installed version which is > causing the action. > In my opinion, the default behaviour should be to never, ever upgrade to a higher slot unless the user forces clearly so. Basically, slots are here to manage different behaving versions of the same package and having GLSA doing a slot upgrade will lead to big troubles, probably. Think of php itself: a glsa for php can cause slot change, from php 4 to php 5. this will lead to a non working site in 99% of cases that I'm aware of. Maybe without security holes, but nonetheless dead. A better option will be to have GLSA to stop and complain loudly. In big installations, a glsa check is usually managed by different people than developers. A minor revision or, even better, a -rX release can be managed quite easily, but a slot upgrade (say, php4->php5) can require a site rewrite. just my 0.2 €.
This bug is no longer valid as we do not have php-5.2.5-r1 in tree.
