app-emulation/wine-0.9: vulnerable via glsa(200601-09) ( ( ver < 20060000 || ver > 20040000 ) && ver not >= 0.9.0 ), affects ('amd64', 'x86') Well, there's never been 0.9.0, only 0.9 :)
i can't reproduce it with glsa-check. I think that the code in pkgcore consider as vulnerable a package which does not match any range, vulnerable range nor unvulnerable range. E.g.: <unaffected range="ge">0.9.0</unaffected> <vulnerable range="lt">20060000</vulnerable> <vulnerable range="gt">20040000</vulnerable> 0.9 is no covered by any of these 3 ranges. glsa-check tells that wine-0.9 is not affected which seems to be the right behaviour to me. NB: this GLSA is buggy, no package could be reported as affected by glsa-check. Another example: GLSA 200405-02: <unaffected range="rge">114i-r2</unaffected> <vulnerable range="rle">114i-r1</vulnerable> this does not affect the versions which do not match /114.*/ and i think this is a right behaviour, since the versioning scheme will probably change. (err.... unaff "rge">114i-r2 is totally useless, i agree)
(In reply to comment #1) > i can't reproduce it with glsa-check. > > I think that the code in pkgcore consider as vulnerable a package which does > not match any range, vulnerable range nor unvulnerable range. E.g.: > > <unaffected range="ge">0.9.0</unaffected> > <vulnerable range="lt">20060000</vulnerable> > <vulnerable range="gt">20040000</vulnerable> > > 0.9 is no covered by any of these 3 ranges. It is covered by the "<vulnerable range="lt">20060000</vulnerable>" range: 0.9 is "smaller than" 20060000 according to portage versioning rules (this is a bit confusing since the 0.9.* packages are actually newer (more recent releases) than the 2006???? ones, which is why the 2006???? ones are in package.mask). > glsa-check tells that wine-0.9 is not affected which seems to be the right > behaviour to me. It looks like this is caused by a difference in how 0.9.0 and 0.9 compare. Portage 2.1.2_pre3-r5 is a bit inconsistent here: the internal comparison code in portage_versions says 0.9.0 and 0.9 are equal, but an attempt to merge '=wine-0.9.0' fails. This is bug 152127.
> It is covered by the "<vulnerable range="lt">20060000</vulnerable>" range: 0.9 > is "smaller than" 20060000 according to portage versioning rules (this is a bit > confusing since the 0.9.* packages are actually newer (more recent releases) > than the 2006???? ones, which is why the 2006???? ones are in package.mask). Yes but glsa-check reports nothing as vulnerable (i have tested with wine-20041019-r3). I don't know what is expected and who should decide what is the good rule. > It looks like this is caused by a difference in how 0.9.0 and 0.9 compare. > Portage 2.1.2_pre3-r5 is a bit inconsistent here: the internal comparison code > in portage_versions says 0.9.0 and 0.9 are equal, but an attempt to merge > '=wine-0.9.0' fails. This is bug 152127. Thanks. This will not be easy to handle. I'll wait for a decision on that bug, then check if glsa-check is consistent with that decision, and finally i think i'll write a few documentation lines on the security policy pages.
(In reply to comment #3) > > It is covered by the "<vulnerable range="lt">20060000</vulnerable>" range: 0.9 > > is "smaller than" 20060000 according to portage versioning rules (this is a bit > > confusing since the 0.9.* packages are actually newer (more recent releases) > > than the 2006???? ones, which is why the 2006???? ones are in package.mask). > > Yes but glsa-check reports nothing as vulnerable (i have tested with > wine-20041019-r3). I don't know what is expected and who should decide what is > the good rule. Funny thing is that 20041019 is vuln. Whee... > > It looks like this is caused by a difference in how 0.9.0 and 0.9 compare. > > Portage 2.1.2_pre3-r5 is a bit inconsistent here: the internal comparison code > > in portage_versions says 0.9.0 and 0.9 are equal, but an attempt to merge > > '=wine-0.9.0' fails. This is bug 152127. > > > Thanks. This will not be easy to handle. I'll wait for a decision on that bug, > then check if glsa-check is consistent with that decision, and finally i think > i'll write a few documentation lines on the security policy pages. Actually, this is easy to fix. <vulnerable range="lt">0.9</vulnerable> <vulnerable range="eq">2004*</vulnerable> <vulnerable range="eq">2005*</vulnerable>
pardon second post... missed something (In reply to comment #3) > > in portage_versions says 0.9.0 and 0.9 are equal, but an attempt to merge > > '=wine-0.9.0' fails. This is bug 152127. > > > Thanks. This will not be easy to handle. I'll wait for a decision on that bug, > then check if glsa-check is consistent with that decision, and finally i think > i'll write a few documentation lines on the security policy pages. That bug will only address the 0.9 edge case; this glsa still is a bit screwed since glsa-check will not properly catch 20040150 (for example); example provided does, and drops the uneccessary (and root of this issue) unaffected tag usage.
worth noting 152127 was corrected; the corner case of atoms is now corrected for portage. Meaning, glsa_check now things 0.9 is vulnerable- solved via correcting the glsas version range from '0.9.0' to '0.9'. CC me if you have questions, but should be pretty straighforward- should be reassigned to security meanwhile, since the glsas are their property.
fixed now
