Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 244803

Summary: glsa-check suggests wrong upgrade path when there is no unaffected version for the slot
Product: Portage Development Reporter: Alexandre Ghisoli <alex>
Component: Third-Party ToolsAssignee: Portage Tools Team <tools-portage>
Status: RESOLVED OBSOLETE    
Severity: normal CC: security
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Alexandre Ghisoli 2008-10-28 18:06:25 UTC
On stable x86, a GLSA is required, but the package is not marked as stable. I cannot find a STABLEREQ on this, so I add this bug as reminder.

Here is the GLSA : 

Checking GLSA 200807-16
The following updates will be performed for this GLSA:
     dev-lang/python-2.4.4-r15 (2.4.4-r14)

But dev-lang/python:2.4 still ~x86 tagged.

eix dev-lang/python
[UD] dev-lang/python
     Available versions:  
        (2.4)   2.4.4-r5 2.4.4-r6 2.4.4-r14 (~)2.4.4-r15
        (2.5)   2.5.2-r7 ~2.5.2-r8
        (2.6)   [M]~2.6-r2
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2008-10-28 18:15:44 UTC
That was handled in bug #230640.
Comment 2 Christian Hoffmann (RETIRED) gentoo-dev 2008-10-28 18:21:46 UTC
I wonder what the problem is here.
  * =dev-lang/python-2.4.4-r14 *is* stable on x86 (as per bug 230640)
  * The GLSA only says >=dev-lang/python-2.4.4-r14

I've got no idea why glsa-check wants to install -r15, which is not stated by the GLSA at all, as far as I can see.
Do you have python in package.keywords*, by chance? If not, this might well be a bug in glsa-check.
Comment 3 Alexandre Ghisoli 2008-10-28 18:47:55 UTC
(In reply to comment #2)
> I wonder what the problem is here.
>   * =dev-lang/python-2.4.4-r14 *is* stable on x86 (as per bug 230640)
>   * The GLSA only says >=dev-lang/python-2.4.4-r14
> 
> I've got no idea why glsa-check wants to install -r15, which is not stated by
> the GLSA at all, as far as I can see.
> Do you have python in package.keywords*, by chance? If not, this might well be
> a bug in glsa-check.
> 

By the time I've created this bug, my package.keywords didn't contain python at all. Right now and to clear this GLSA, I've added python.

I can revert to the last status. As I can read in your comment and the bug, python-2.4.4-r14 is safe regarding to the GLSA 200807-16.
Comment 4 Christian Hoffmann (RETIRED) gentoo-dev 2008-10-28 18:55:16 UTC
> By the time I've created this bug, my package.keywords didn't contain python at
> all. Right now and to clear this GLSA, I've added python.
> 
> I can revert to the last status. As I can read in your comment and the bug,
> python-2.4.4-r14 is safe regarding to the GLSA 200807-16.
Yes, the mentioned bug is fixed in -r14 already. -r15 fixes yet another security-related issue (see bug 238124), but it hasn't been stabled yet and there is no GLSA yet (rather an edge case).
Comment 5 Alexandre Ghisoli 2008-10-28 19:10:42 UTC
Ok, I think I've spotted the issue; it's a old python-2.3 installed that cause the GLSA to be bring up.

If I remove python-2.3, no more GLSA.

Comment 6 Robert Buchholz (RETIRED) gentoo-dev 2008-10-28 19:53:51 UTC
Let's recap:

Python 2.3 is installed and vulnerable
Python 2.4 is installed and not vulnerable.

glsa-check is looking for an upgrade path for 2.3, finds a (not installed) 2.4 version that is unaffected as the least upgrade path. The GUI then suggests this upgrade, showing the version in the same slot as "upgrading from" (which is to be interpreted as "this is vulnerable").

This bug in glsa-check needs a redesign of the way glsa-check handles the correlation of affected and unaffected packages. I prepared patches[1] for this some time ago, but genone had some issues with them that prevented their commits.

Genone: Can we discuss the issues here?

[1]
http://git.goodpoint.de/?p=glsa-check.git;a=commit;h=e6f26cc02b5207ff33289c20d751a0d4fb1122bc
http://git.goodpoint.de/?p=glsa-check.git;a=commit;h=bce832dc31cfa297de72aab6b3f39278a8612a1d
Comment 7 michael@smith-li.com 2009-01-25 00:21:06 UTC
Would it not make sense to have glsa-check just refuse to automatically upgrade to a version in a different SLOT?
Comment 8 Robert Buchholz (RETIRED) gentoo-dev 2009-01-25 02:20:31 UTC
That wouldn't make sense in a lot of fine grained slotted environments, i.e. web-apps. Furthermore, refer to the Python example given above.

What do others think of the patches? I think they might not cleanly apply to current portage trunk, but I'd still like some feedback if I'm to rebase them.
Comment 9 Tobias Heinlein (RETIRED) gentoo-dev 2016-10-09 12:20:51 UTC
This bug report is ancient and has been fixed ever since commit acdf616e: glsa-check only suggests upgrade paths if ebuilds of unaffected candidate atoms are in the same SLOT.