Summary: | dev-qt/qtwebkit: QtWebKit logs visited URLs to WebpageIcons.db in private browsing mode | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED OBSOLETE | ||
Severity: | trivial | CC: | qt |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugzilla.redhat.com/show_bug.cgi?id=1204795 | ||
Whiteboard: | ~3 [ebuild+] | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 620684 | ||
Bug Blocks: |
Description
Agostino Sarubbo
2015-03-24 13:28:58 UTC
The fix is part of 5.4.2 which is stable in-tree, but apparently affects qtwebkit:4 too. Fedora has a patch [1] against qtwebkit23, i.e. our qtwebkit-4.10.4 [1] http://pkgs.fedoraproject.org/cgit/qtwebkit.git/plain/webkit-qtwebkit-23-private_browsing.patch Per upstream commit this is included in the 5.4 branch which is currently stable in the tree. @maintainers, I imagine the 4.8.x branch will be around for awhile. Is it feasible to include the referenced patch on all 4.8.x stable versions? (In reply to Aaron Bauman from comment #3) > @maintainers, I imagine the 4.8.x branch will be around for awhile. Is it > feasible to include the referenced patch on all 4.8.x stable versions? Fedora's patch is against qtwebkit-4.10.4, which is in-tree but hard-masked and will require a lot of integration work to be usable. The file being patched doesn't even existing in qtwebkit-4.8.x so it will need investigation whether it's possible to port or not. Considering that Qt 4 is EOL and how behind qtwebkit in general is, I wonder if it's time to start investigating revdeps and avoid usage where possible. (In reply to Michael Palimaka (kensington) from comment #4) > Considering that Qt 4 is EOL and how behind qtwebkit in general is, I wonder > if it's time to start investigating revdeps and avoid usage where possible. I concur. I don't even want to think about how many security issues affect qtwebkit-4.8.x at this point... (In reply to Michael Palimaka (kensington) from comment #4) > (In reply to Aaron Bauman from comment #3) > > @maintainers, I imagine the 4.8.x branch will be around for awhile. Is it > > feasible to include the referenced patch on all 4.8.x stable versions? > > Fedora's patch is against qtwebkit-4.10.4, which is in-tree but hard-masked > and will require a lot of integration work to be usable. > > The file being patched doesn't even existing in qtwebkit-4.8.x so it will > need investigation whether it's possible to port or not. > > Considering that Qt 4 is EOL and how behind qtwebkit in general is, I wonder > if it's time to start investigating revdeps and avoid usage where possible. That looks to me like the issue has been mitigated than concerning 4.10.4. I cannot find anywhere (CVE's, OSS, etc) confirming that 4.8.x contains the same vulnerability. As you mentioned, the source file does not even exist so that rules out finding the same code. Would you like to keep this bug open for any other tracking issues? (In reply to Aaron Bauman from comment #6) > (In reply to Michael Palimaka (kensington) from comment #4) > > (In reply to Aaron Bauman from comment #3) > > > @maintainers, I imagine the 4.8.x branch will be around for awhile. Is it > > > feasible to include the referenced patch on all 4.8.x stable versions? > > > > Fedora's patch is against qtwebkit-4.10.4, which is in-tree but hard-masked > > and will require a lot of integration work to be usable. > > > > The file being patched doesn't even existing in qtwebkit-4.8.x so it will > > need investigation whether it's possible to port or not. > > > > Considering that Qt 4 is EOL and how behind qtwebkit in general is, I wonder > > if it's time to start investigating revdeps and avoid usage where possible. > > That looks to me like the issue has been mitigated than concerning 4.10.4. > I cannot find anywhere (CVE's, OSS, etc) confirming that 4.8.x contains the > same vulnerability. As you mentioned, the source file does not even exist > so that rules out finding the same code. Would you like to keep this bug > open for any other tracking issues? While the source file does not exist, the code referenced in the patch does appear in another file. I can't say for certain whether it's really affected or not. qtwebkit:4 has been treecleaned. |