Summary: | glsa-check gives false alarm GLSA 201408-11 for =dev-lang/php-5.4.34 | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Tomáš Mózes <hydrapolic> |
Component: | GLSA Errors | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | c.burger, hanno |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | correct the range of affected versions for GLSA 201408-11 |
Description
Tomáš Mózes
2014-10-24 08:11:10 UTC
Please post your `emerge --info dev-lang/php; emerge -vpq dev-lang/php' output in a comment. # emerge --info dev-lang/php dev-lang/php-5.4.34 was built with the following: USE="apache2 bcmath berkdb bzip2 calendar cli crypt ctype curl fileinfo filter gdbm gmp hash iconv inifile intl json mhash mysql mysqli nls pdo phar posix readline session simplexml soap sockets ssl sysvipc tokenizer unicode xml xmlreader xmlwriter zip zlib -cdb -cgi -cjk -curlwrappers -debug -embed -enchant -exif (-firebird) -flatfile -fpm -ftp -gd -imap -iodbc -ipv6 -kerberos -ldap -ldap-sasl -libedit -mssql -mysqlnd -oci8-instant-client -odbc -pcntl -postgres -qdbm -recode (-selinux) -sharedmem -snmp -spell -sqlite (-sybase-ct) -systemd -threads -tidy -truetype -wddx -xmlrpc -xpm -xslt" ABI_X86="64" # emerge -vpq dev-lang/php [ebuild R ] dev-lang/php-5.4.34 USE="apache2 bcmath berkdb bzip2 calendar cli crypt ctype curl fileinfo filter gdbm gmp hash iconv inifile intl json mhash mysql mysqli nls pdo phar posix readline session simplexml soap sockets ssl sysvipc tokenizer unicode xml xmlreader xmlwriter zip zlib -cdb -cgi -cjk -curlwrappers -debug -embed -enchant -exif (-firebird) -flatfile -fpm -ftp -gd -imap -iodbc -ipv6 -kerberos -ldap -ldap-sasl -libedit -mssql -mysqlnd -oci8-instant-client -odbc -pcntl -postgres -qdbm -recode (-selinux) -sharedmem -snmp -spell -sqlite (-sybase-ct) -systemd -threads -tidy -truetype -wddx -xmlrpc -xpm -xslt" I can confirm that.
'glsa-check' as well as 'cave report' seem to think the GLSA applies to 5.4.
The culprit seems to be the 'rge' instead of just an 'ge' here:
<unaffected range="ge">5.5.16</unaffected>
<unaffected range="rge">5.4.32</unaffected>
<unaffected range="rge">5.3.29</unaffected>
<vulnerable range="lt">5.5.16</vulnerable>
According to the documentation (see below), this limits the unaffected only to version 5.4 and 5.3. Don't know what the intention was, but I suspect a copy-and-paste accident here.
> handler for the special >~, >=~, <=~ and <~ atoms that are supposed to behave
> as > and < except that they are limited to the same version, the range only
> applies to the revision part.
I assume as soon as a version >5.3.29 appears, it will be marked accordingly. I will attach a patch, which removes the prefixed "r" and adds "lt" entries for slots 5.3 and 5.4 as well, just to be thorough.
Created attachment 388434 [details, diff]
correct the range of affected versions for GLSA 201408-11
I apologize for this taking so long. I have updated GLSA 201408-11 with the new, unaffected version. We should have a new GLSA released soon for bug 525960. Please re-sync and re-open this bug if you continue to have any glsa-check warnings on =dev-lang/php-5.4.34. Thanks, it works. However is it correct this way? <package name="dev-lang/php" auto="yes" arch="*"> <unaffected range="ge">5.5.16</unaffected> <unaffected range="rge">5.4.32</unaffected> <unaffected range="rge">5.3.29</unaffected> <unaffected range="rge">5.4.34</unaffected> <vulnerable range="lt">5.5.16</vulnerable> </package> I have the same suspicion as Tomas. Set like this, we probably will re-open this bug or someone will make a new one as soon as some new version like 5.4.35 stabilizes in the Gentoo tree. This could go on forever.
Could you explain the reason behind doing it that way? The patch I supplied would probably work in the long term.
What am I missing?
PS: I just saw an oversight in my last comment, I meant to say:
> According to the documentation (see below), this limits the unaffected only to
> version ~5.4.32 and ~5.3.29
(In reply to Christian Burger from comment #7) > Could you explain the reason behind doing it that way? The patch I supplied > would probably work in the long term. This is a long standing issue, see bug 106677 for more information. Thanks for your patch, but I'm afraid it won't work like that. The ranges in your patch don't understand SLOTs, so just using <unaffected range="ge">5.3.29</unaffected> instead of <unaffected range="rge">5.3.29</unaffected> will also mark *any* 5.4 and 5.5 greater than or equal to 5.3.29 as unaffected. Our workaround for now has always been to update the GLSA and add 'rge' entries for all new versions in SLOTs except the "highest" one, or update the GLSA with a version that's available in the Portage tree, depending on the case. Sean chose the latter here. (In reply to Tobias Heinlein from comment #8) > This is a long standing issue, see bug 106677 for more information. Ah, thank you for taking the time to quench my curiosity. > Thanks for your patch, but I'm afraid it won't work like that. The ranges in > your patch don't understand SLOTs, so just using > <unaffected range="ge">5.3.29</unaffected> > instead of > <unaffected range="rge">5.3.29</unaffected> > will also mark *any* 5.4 and 5.5 greater than or equal to 5.3.29 as > unaffected. This was my first assumption, when I saw the "rge" parameter, but then I took a look around and found this in /usr/portage/metadata/glsa/glsa-201209-03.xml <unaffected range="ge">5.3.15</unaffected> <unaffected range="ge">5.4.5</unaffected> <vulnerable range="lt">5.3.15</vulnerable> <vulnerable range="lt">5.4.5</vulnerable> thus I assumed copy-n-paste error. So basically, in 201209-03 every 5.4.* is in the clear because of <unaffected range="ge">5.3.15</unaffected> ? And this GLSA is incorrect -- though it doesn't hurt anymore? While I was poking around in the Paludis code I saw a "slot" parameter for <unaffected/> and <vulnerable/>, but when I was trying it, 'cave report' warned me that it's not safe to use. Saw the code for handling "slot" in 'glsa-check', too. Anyway, I will take any further opinion of mine over to #106677 -- should I come to one. |