Bugzilla Bug 79720

x11-misc/xfontselector-0.9.2 depends on =qt-2*

'glsa-check -t all' indicates that the installed qt-2.3.2-r1 is vulnerable to GLSA 200408-20. I've checked bugtraq report 10977 and found that qt-2.3.1 was vulnerable and fixed by TurboLinux. Also checked QT-2.3.2 Changes page and found nothing about the vulnerability (or couldn't find, so I ask someone to confirm that).

I'll leave this issue to be confirmed by the experts.

References:

GLSA 200408-20 / QT - http://security.gentoo.org/glsa/glsa-200408-20.xml
bugtraq id 10977 - http://www.securityfocus.com/bid/10977/info/
Trolltech QT-2.3.2 Changes - http://www.trolltech.com/developer/changes/changes-2.3.2.html

kde/desktop-misc please verify and advise.

It seems likely that the old qt version is vulnerable, at least it was released before the vulnerability was fixed and version 2.3.1 is vulnerable according to the sources mentioned.

kde/desktop-misc please comment. Otherwise we'll have to mask the package soon.

This project has been inactive for almost three years, it should just be 
masked, and removed from portage shortly after that.

desktop-misc please comment/react on comment #3

No response from desktop-misc and dead upstream. I think it should be masked
prior to removal.

vapier/solar please do the vodoo.

This now package.masked per request

I just found that app-admin/qtsvc is in the same situation as xfontselector.

Another one to mask?

KDE herd: if qtsvc requires a vulnerable QT then yes, it should be masked (or
removed)... If it can be adapted to use a fixed QT, then it should be
patched...

Your input needed :)

Added app-admin/qtsvc to package.mask.

There's only one other packages that explicitly depends on qt-2: games-roguelike/slashem (games herd).

Games herd, slahem should probably be package.masked because it depends on a
vulnerable QT lib (or fixed to accept a fixed QT lib dependency).

Chris/vapier: *bump*

The bugtraq entry lists quite a number of affected Qt versions, but not 2.3.2.
According to their advisories Debian and Suse (the N. corporate website design
sux, btw.) had to address only Qt 3. Do we have to investigate or can we try to
get rid of Qt 2 at all?!

i'm not quite sure i understand ...

is qt-2.x vuln or not ?

slashem has *optional* qt support, so we could just force -qt on it until it works with qt-3.x, or someone fixes qt-2.x (assuming it is vuln)

Carsten, If you want to keep qt-2 in the tree please investigate otherwise
we'll just have to flush it when all deps are removed.

SpanKY, that sounds like an acceptable solution.

It's okay with me to get rid of Qt2 and all of the packages that depend upon it
- however, I'm not entirely sure that this bug affects Qt2.  Either way, the
latest version is like 2.3.7, and ours is 2.3.2.  I would think very few people
run Qt2 anymore, except as a direct result of an older program that relies on
it.

Caleb, I'm not sure this affects QT2 either. But if we have no pkgs using it I
see no reason to keep it in the tree and the remaining packages seems rather
minor. 

Otherwise someone will have to take the time and debunk this for QT2.

just because we're not using it doesnt mean people arent utilizing binary-only
apps with a qt-2 frontend ...

i'd rather not punt the lib if it's not vuln and it's not really causing any
problems otherwise ...

> If you want to keep qt-2 in the tree

No interest, but SpanKy may be right. According to the bugtray entry Qt 2.3.1 is vulnerable, but it doesn't say anything about other Qt 2 versions. I for one would prefer if we get rid of all dependencies in the tree, update to the latest version and package mask it after six weeks or so. Everyone who really needs it can grab it then, but we don't have to support it anymore.

Caleb you could post to -dev to see the reaction? I see no great reason to keep
it in the tree if the owner herd wants it removed.

Anyone read through the changelogs up to the newest version or looked at ie.
Debian?

Call me crazy, but qt-2.3.2-r2 is set to build against the system png and jpeg
libraries (-system-libpng -system-libjpeg), which would indicate to me that as
long as those libraries are safe, that Qt is safe.

Thoughts?

(The changelog for Qt2 on Trolltech's site makes no mention of this fix for
this series).

SpanKY please advise.

i looked on the trolltech website and didnt see a version newer than 2.3.2 ...

either way, the fix is pretty easy to obtain by doing a diff between the 3.3.2 and 3.3.3 versions

Created an attachment (id=57516) [details]
qt-2.3.2-bmp.patch

SpanKY: Fixing Qt-2.3 is one thing, but the idea is more to phase it out and
remove all dependencies on it in the tree.

There are also issues with PNG, XPM, GIF and JPEG image types. The detailed BMP
reference were only for the PoC. 

ok, well i'd prefer to keep qt-2* regardless, but i'm not the maintainer so i
dont really have say

if maintainer wishes to punt the pkg then i'll just update slashem and drop the
qt frontend

dropped slashem-0.0.760's qt support since no one really cares :p

Carlo will you remove old vulnerable QT ebuilds?

SpanKY: I'd maybe care, if newer Qt 2.x versions would be made available by
Trolltech. No general upstream support, no support by us, either.

Sune: app-admin/qtsvc and x11-libs/qt-2* are gone, we're clean. :)

Thx Carsten. Waiting for the removal of x11-misc/xfontselector before closing.

Yes, that was really a "great job" of mine. Missed xfontselector and
unixODBC-2.0.8 as well. Once again and you can name me the broken tree dude.

Thx Carsten, I guess noone discovered it this time. 
 
We're ready to close the bug.