| Summary: | app-emulation/emul-linux-x86-qtlibs(?): khtml/qt integer overflow (CVE-2006-4811) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Matthias Geerdsen (RETIRED) <vorlon> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | blubb, dystopianray |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | B2 [glsa] | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 165270 | ||
|
Description
Matthias Geerdsen (RETIRED)
2006-11-01 08:49:54 UTC
ok... i have tried to get a comment from amd64 on the other bug before, pinged people in #-dev a long while ago... well... CC'ing amd64, pls validate baselibs, qtlibs and gtklibs need new versions. I'll try to see if I can do it next weekend if herbs doesn't get to it first. I personally have no clue on how the package is built these days, sorry :-/ Should remove myself from metadata.xml i suppose :-) tester, any news on this one? hmpf... it has been over a month now has there been any progress here? reping PONG! I've got emul-linux-x86-qtlibs-10.0 ready. The SRC_URI files are uploading right now, so I can commit the the ebuild in ~4h. Uhm, actually, not quite yet, as this also needs a new baselibs which is quite some work, but "we're working on it". (In reply to comment #8) > Uhm, actually, not quite yet, as this also needs a new baselibs which is quite > some work, but "we're working on it". > OK :) 10.0 is in the tree, marked ~amd64. Since it required a complete rebuild of ~40 packages, I'd like to wait a bit before stablizing it, I'm almost sure something broke. It's not like a few more days would hurt after 3 1/2 months anyway... Alright, it worked out a lot better then I expected it to, so emul-linux-x86-qtlibs-10.0 which fixes the issue is marked stable on amd64 now. Updating these ebuilds seems to have broken the other emul-linux-x86-* ebuilds that are still putting things in /emul. I had to update emul-linux-x86-sdl and emul-linux-x86-gtklibs to the ~arch versions that put everything in /lib32 and /usr/lib32 or their libraries weren't being detected and revdep-rebuild was spitting out missing library errors. (In reply to comment #12) > Updating these ebuilds seems to have broken the other emul-linux-x86-* ebuilds > that are still putting things in /emul. Thanks for catching that, I had this mix installed thus it worked fine. I just marked all the latest emul-packages stable so everything goes to (/usr)/lib32. Thanks to all the developers and testers :) it's A2 or B2 so it merits a GLSA. this was GLSA 200703-06 so let's close it :) |