We currently have a problem with the following kind of GLSA : ------------------------------- Affected : <=2.4.9 Unaffected : >=2.4.9-r1 , <2.0 ------------------------------- which is our way to say "2.x up to 2.4.9 is affected". If you have only one version installed everything is OK. If you have multiple SLOTs installed (as in the case of gtk+ with the recent GLSA 200409-28), it works well as far as upgrade is concerned ("glsa-check -f"), but the system is still listed as vulnerable when you use "glsa-check -p" or "glsa-check -l". It's because the upgradepath functions in glsa-check take into account both vulnerable and unaffected conditions, while the "isVulnerable" function only takes into account the vulnerable conditions. isVulnerable currently works like this : vulnerable = (vuln_condition_1) OR (vuln_cond_2) OR ... What we need is : vulnerable = ((vuln_condition_1) OR (vuln_condition_2) ... ) AND NOT ((unaf_condition_1) OR (unaf_condition_2) ... ) With this improvement, the way we write these "range" GLSAs would work, without the need for a specific range operator to be included in portage. You could just add a pass in isVulnerable to remove unaffected versions from the vulnerable list.
Using this bug as a tracker, it's the same issue I sent you by mail. Tested glsa-new.diff patch : The system is listed as unaffected by every GLSA (while it is affected by some).
*** Bug 66323 has been marked as a duplicate of this bug. ***
I think this might be related (if it's not please tell me so, I would gladly file another bug): with GLSA 200410-04 (php stuff) glsa-check --test says the system is unaffected and so does --list. But the system is in fact affected and glsa-check -p and -f even give the correct upgrade command. For more details: gentoolkit 0.2.0_pre9 GLSA requires php versions >=4.3.9 for three packages (php, mod_php, php-cgi) while the system has only two of them at 4.3.8 (php, mod_php). glsa-check --test 200410-04 says: This system is not affected by any of the listed GLSA. glsa-check -p 200410-04 says: Checking GLSA 200410-04 The following updates will be performed for this GLSA: dev-php/mod_php-4.3.9 (4.3.8) dev-php/php-4.3.9 (4.3.8) I thought this was related because of what Koon had said in comment 1: "The system is listed as unaffected by every GLSA (while it is affected by some)."
please test with gentoolkit-0.2.0_pre10 and report back.
gentoolkit-0.2.0_pre10: Ok, false negative is gone, all of -t, -p, -f and -l show that the system is affected. Although now there is another problem: the suggested versions are ~keyword masked. Back to 200410-04: glsa-check -p 200410-04 now says: Checking GLSA 200410-04 The following updates will be performed for this GLSA: dev-php/mod_php-5.0.1 (4.3.8) dev-php/php-5.0.0-r1 (4.3.8) and glsa-check -p will in fact try to emerge that versions while emerge mod_php selects unmasked 4.3.9 versions as expected. In gentoolkit-0.2.0_pre9 glsa-check -p selects 4.3.9. Found one other GLSA where ~keyword masked version exists. It's 200408-23 and deals with kdelibs. glsa-check -p selects kdelibs-3.2.3-r2 while emerge with AK=~x86 would select kdelibs-3.3.0. Thus the problem seems to be 200410-04 specific (have not found more GLSAs to test with, haven't tried to look harder though).
The range thing is corrected, so this is closed/fixed. The masked thing is a new one, handled by bug 73537. Antanas, please followup there.
