Hello. Some time ago I've upgraded to python-2.4.1. The old version was still installed on my system, and glsa-check reported about vulnerability. camobap glsa # glsa-check -p 200509-08 Checking GLSA 200509-08 The following updates will be performed for this GLSA: dev-lang/python-2.3.5-r2 (2.3.5) But suggestion to update python was wrong. Look command: emerge --ask --oneshot --verbose ">=dev-lang/python-2.3.5-r2" reemerge python-2.4.1 for me and does not touch python-2.3.5. Thus glsa shoud somehow check for problems in slotted apps and report more sane suggestion like: emerge --ask --oneshot =dev-lang/python-2.3.5-r2 Or may be some other way... Any way. Thank you for your attention, Peter. Reproducible: Always Steps to Reproduce:
Not a problem in glsa-check but the GLSA text.
Reassigning to GLSA errors
I would like to add to this one. The output from "glsa-check --list" is confusing for slotted packages. For example, GLSA 200607-02 identifies all versions of media-libs/freetype before 2.1.10-r2 as being vulnerable. However, I can see that I have media-libs/freetype-2.1.10-r2 installed, so I get confused because it seems my system is already up-to-date. The explanation is that media-libs/freetype-1.3.1-r4 is also installed on my system. I suggest that it would be a nice improvement if "glsa-check --list" would list the precise vulnerable versions.
*** Bug 143989 has been marked as a duplicate of this bug. ***
So is anyone working on adding slot support? If so i'd like to help out.. (put this whole social workspaces thing to use :) )
reviving this bug... glsa-check is really missing support for ranges in affected/unaffected versions, which would really help a lot when doing GLSAs for slotted packages (esp. PHP etc.). The current situation of updating old PHP GLSAs when new versions come out is seriously annoying. So are there any planned changes for glsa-check? I know this has been discussed before with koon for example, but what was/is the actual outcome?
No. If such a feature gets implemented it's at the portage level, but I don't see that happening anytime soon (at least not by me). The revision-range hack is already bad enough. *Maybe* if I find the time I'll add support for slot deps, but that's a big "if" currently. However, any such extension is going to require a versioning system (e.g. a <glsa-version> tag) for glsas so glsa-check (and other tools) can check if they can process a given glsa. And to be effective this would have to be deployed quite some time before any extension could be used.
This is now really annoying regarding 200702-07 (java stuff): --8<-- vesta ~ # glsa-check -p affected Checking GLSA 200702-07 The following updates will be performed for this GLSA: dev-java/sun-jre-bin-1.5.0.10 (1.4.2.14) dev-java/sun-jdk-1.5.0.11 (1.4.2.14) vesta ~ # qlist -Iv dev-java/sun- dev-java/sun-jdk-1.4.2.14 dev-java/sun-jdk-1.5.0.11-r1 dev-java/sun-jdk-1.6.0-r2 dev-java/sun-jre-bin-1.4.2.14 dev-java/sun-jre-bin-1.5.0.11 dev-java/sun-jre-bin-1.6.0-r1 vesta ~ # egrep '(package|range=)' /usr/portage/metadata/glsa/glsa-200702-07.xml <package name="dev-java/sun-jdk" auto="yes" arch="*"> <unaffected range="ge">1.5.0.10</unaffected> <unaffected range="rge">1.4.2.13</unaffected> <vulnerable range="lt">1.5.0.10</vulnerable> <vulnerable range="lt">1.4.2.13</vulnerable> </package> <package name="dev-java/sun-jre-bin" auto="yes" arch="*"> <unaffected range="ge">1.5.0.10</unaffected> <unaffected range="rge">1.4.2.13</unaffected> <vulnerable range="lt">1.5.0.10</vulnerable> <vulnerable range="lt">1.4.2.13</vulnerable> </package> vesta ~ # --8<--
r403 of glsa-check has now some basic support for checking $SLOT when selecting/displaying upgrades. As for slot support in GLSAs, portage has now support for slot-deps, but for using this the second part of comment #7 must first be taken care of.
This also affects python 2.5 users for GLSA 200711-07. Marius, what's the status of SLOT support or security support in portage?
(In reply to comment #10) > This also affects python 2.5 users for GLSA 200711-07. > > Marius, what's the status of SLOT support or security support in portage? Please define "SLOT support" and "security support in portage", unless you only refer to using slot deps in GLSAs, in that case my previous comments still apply. I guess the main problem there is that nobody feels responsible for glsa.dtd anymore.
(In reply to comment #11) > (In reply to comment #10) > > This also affects python 2.5 users for GLSA 200711-07. > > > > Marius, what's the status of SLOT support or security support in portage? > > Please define "SLOT support" and "security support in portage", unless you only > refer to using slot deps in GLSAs, in that case my previous comments still > apply. I guess the main problem there is that nobody feels responsible for > glsa.dtd anymore. Sorry for being unclear. With SLOT support I meant this problem: GLSA 200711-07 marks ">= 2.4.4-r6" as unafected, but because of SLOTing, Python 2.5* is found to be affected by glsa-check. Is that what you call GLSA SLOT deps? By security support in Portage I meant your integration of glsa checking and fixing without glsa-check, by "emerge security". What changes in the DTD would you need?
(In reply to comment #12) > Sorry for being unclear. With SLOT support I meant this problem: > GLSA 200711-07 marks ">= 2.4.4-r6" as unafected, but because of SLOTing, Python > 2.5* is found to be affected by glsa-check. > > Is that what you call GLSA SLOT deps? You could use the "rge" operator in the GLSA to only include revisions of 2.4.4 (though if python-2.4.5 would come along you'd have the opposite problem) > By security support in Portage I meant your integration of glsa checking and > fixing without glsa-check, by "emerge security". That's in portage-2.2 > What changes in the DTD would you need? As I said, the first requirement would be some kind of versioning, otherwise we get into the same situation as with portage and ebuilds where format extensions break older versions of the application. Only then can we talk about how to specify slot deps in the GLSA syntax.
(In reply to comment #13) > (In reply to comment #12) > > Sorry for being unclear. With SLOT support I meant this problem: > > GLSA 200711-07 marks ">= 2.4.4-r6" as unafected, but because of SLOTing, Python > > 2.5* is found to be affected by glsa-check. > > > > Is that what you call GLSA SLOT deps? > > You could use the "rge" operator in the GLSA to only include revisions of 2.4.4 > (though if python-2.4.5 would come along you'd have the opposite problem) Actually forget what I said (I misread your statement, 2.5 should not be considered affected as its not matched by the <vulnerable> section. If it is please open a separate bug about it (including the exact commands you used and their full output)
Actually, never mind. Robert’s comment 10 was due to the situation on my machine, with Python 2.5 installed; glsa-check was justified in matching the GLSA, though, because there was also an old Python 2.4 that I didn’t know I had (and which had escaped updates until now). So no problem with that, and sorry to have wasted your time.
Any updates on this? Running "glsa-check -p affected" now looks like this for one my system: # glsa-check -p affected Checking GLSA 200804-20 The following updates will be performed for this GLSA: dev-java/sun-jdk-1.6.0.05 (1.6.0.07) Checking GLSA 200806-10 The following updates will be performed for this GLSA: media-libs/freetype-2.3.6 (2.3.7) Checking GLSA 200705-23 The following updates will be performed for this GLSA: dev-java/sun-jdk-1.5.0.15 (1.6.0.07) # equery l freetype [ Searching for package 'freetype' in all categories among: ] * installed packages [I--] [ ] media-libs/freetype-1.4_pre20080316-r1 (1) [I--] [ ] media-libs/freetype-2.3.7 (2) # equery l sun-jdk [ Searching for package 'sun-jdk' in all categories among: ] * installed packages [I--] [ ~] dev-java/sun-jdk-1.4.2.18 (1.4) [I--] [ ~] dev-java/sun-jdk-1.5.0.16 (1.5) [I--] [ ~] dev-java/sun-jdk-1.6.0.07 (1.6)
Freetype being listed is an error in the GLSA, we will be issueing an Errata GLSA in bug 225851. As for GLSA slot support, this has been discussed in the last security team meeting, and we will push forward a design proposal soon.
Created attachment 166686 [details, diff] GLSA-SLOT-support-in-vulnerable-unaffected-package.patch Patch to the GLSA DTD v2 to support SLOT definitions in affected/unaffected packages.
any news on glsa-check + slotted packages?
*** Bug 497322 has been marked as a duplicate of this bug. ***
*** Bug 522834 has been marked as a duplicate of this bug. ***
yay! Thanks to Alex, Tobias, and Mart!
