[arch-dev-public] Phasing out webkitgtk{,2}
Hello list, WebkitGTK+ 2.4 has been unmaintained for quite a while, and lots of CVEs have accumulated. The last release fixing CVEs, 2.4.10, only fixed about half the vulnerabilities known, and that release was only made because 2.4.9 was broken with GTK+ 3.20, and Evolution quickly needed a working HTML renderer. For more information about the WebKit situation, take a look at https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/ We currently have the following packages depending on webkitgtk: webkitgtk ├─balsa ├─eclipse-common │ ├─eclipse-cpp │ ├─eclipse-java │ ├─eclipse-jee │ └─eclipse-php ├─empathy ├─geary ├─gnome-web-photo ├─gtkpod ├─liferea ├─midori ├─uzbl-core │ └─uzbl-browser │ └─uzbl-tabbed ├─variety ├─webkitgtk-sharp │ └─sparkleshare └─xombrero And, for webkitgtk2: webkitgtk2 ├─atril ├─boinc ├─codeblocks ├─dwb ├─geany-plugins ├─gnucash ├─gphpedit ├─guitarix2 ├─java-openjfx │ └─pdfsam ├─java-openjfx-doc ├─java-openjfx-src ├─luakit ├─midori-gtk2 ├─moneymanagerex ├─osmo ├─pan ├─perl-gtk2-webkit ├─python2-deepin-utils │ └─python2-deepin-ui │ ├─deepin-game │ └─deepin-music ├─pywebkitgtk │ ├─python2-deepin-ui │ ├─python2-deepin-utils │ ├─python2-jswebkit │ │ └─deepin-game │ └─screenlets │ └─screenlets-pack-basic ├─surf └─webkit-sharp ├─blam └─mono-tools To protect our users we should try to limit the packages using webkitgtk(2)., with the goal of eventually getting rid of it completely. I propose making a TODO that covers all these packages, with the following policy: - If it can be updated to webkit2gtk, do so. - Otherwise, if WebKit is an optional dependency, build without it. - Otherwise, consider removing the package, especially if it's a browser. Thoughts? Greetings, Jan
As the maintainer of one of those browsers, I'll also be prodding upstream about the issue if it can't easily be updated. The last time this came up (Dec 2015), Xombrero's author said
We briefly looked at the 2.x stuff but that would basically be a rewrite and even more unfortunate is that not all required hooks to make a “secure” browser are available.
He's an OpenBSD dev too, so it isn't like people have to explain the usefulness of security to him. We'll see how it goes. Contacting upstream (either with patches or "hey, we are going to have to remove your software from our repos") should be a fourth step on the policy. -Kyle http://kmkeen.com
[2017-01-18 22:42:38 +0000] Jan Alexander Steffens via arch-dev-public:
WebkitGTK+ 2.4 has been unmaintained for quite a while, and lots of CVEs have accumulated. The last release fixing CVEs, 2.4.10, only fixed about half the vulnerabilities known, and that release was only made because 2.4.9 was broken with GTK+ 3.20, and Evolution quickly needed a working HTML renderer.
For more information about the WebKit situation, take a look at https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/
We currently have the following packages depending on webkitgtk:
webkitgtk ├─balsa ├─eclipse-common │ ├─eclipse-cpp │ ├─eclipse-java │ ├─eclipse-jee │ └─eclipse-php ├─empathy ├─geary ├─gnome-web-photo ├─gtkpod ├─liferea ├─midori ├─uzbl-core │ └─uzbl-browser │ └─uzbl-tabbed ├─variety ├─webkitgtk-sharp │ └─sparkleshare └─xombrero
And, for webkitgtk2:
webkitgtk2 ├─atril ├─boinc ├─codeblocks ├─dwb ├─geany-plugins ├─gnucash ├─gphpedit ├─guitarix2 ├─java-openjfx │ └─pdfsam ├─java-openjfx-doc ├─java-openjfx-src ├─luakit ├─midori-gtk2 ├─moneymanagerex ├─osmo ├─pan ├─perl-gtk2-webkit ├─python2-deepin-utils │ └─python2-deepin-ui │ ├─deepin-game │ └─deepin-music ├─pywebkitgtk │ ├─python2-deepin-ui │ ├─python2-deepin-utils │ ├─python2-jswebkit │ │ └─deepin-game │ └─screenlets │ └─screenlets-pack-basic ├─surf └─webkit-sharp ├─blam └─mono-tools
To protect our users we should try to limit the packages using webkitgtk(2)., with the goal of eventually getting rid of it completely. I propose making a TODO that covers all these packages, with the following policy:
- If it can be updated to webkit2gtk, do so. - Otherwise, if WebKit is an optional dependency, build without it. - Otherwise, consider removing the package, especially if it's a browser.
Thoughts?
Sounds good to me. I know many of us won't be happy to see packages we rely on dropped to the AUR, but it's either that or a myriad of security holes: the choice is clear to me. Cheers. -- Gaetan
2017-01-18 23:42 GMT+01:00 Jan Alexander Steffens via arch-dev-public < arch-dev-public@archlinux.org>:
To protect our users we should try to limit the packages using webkitgtk(2)., with the goal of eventually getting rid of it completely. I propose making a TODO that covers all these packages, with the following policy:
- If it can be updated to webkit2gtk, do so. - Otherwise, if WebKit is an optional dependency, build without it. - Otherwise, consider removing the package, especially if it's a browser.
Thoughts?
+1 I think we should drop every applications that use WebkitGTK+ to render HTML content from insecure sources (e.g. allow to load web pages or open any local HTML files). If an application loads some internal HTML content only, and there is no alternative renderer, then it's okay to keep it. We should consider the same thing for qtwebkit, which is unmaintained too, but it affects much more packages. About my packages: - blam, gnome-web-photo, screenlets, screenlets-pack-basic: these are unmaintained by upstream a long time ago, therefore I'll drop them. - sparkleshare, webkitgtk-sharp: git master uses webkit2gtk (trough webkit2-sharp), so I'll update sparkleshare, and drop webkitgtk-sharp. - pywebkitgtk: I'll orphan this package, still used by others. -- György Balló Trusted User
El Thu, 19 Jan 2017 01:14:27 +0100, Balló György via arch-dev-public escribió:
We should consider the same thing for qtwebkit, which is unmaintained
too,
but it affects much more packages.
Not really. The reverse dependency list is big because it contains KDE4, but there are already patches around to strip off webkit from kdelibs. Once that is sorted out, the number of packages that link to qtwebkit is not that big: acetoneiso2 bibletime clipgrab fcitx-libpinyin freecad freemat gambas3-gb-qt4-webkit kbibtex kchmviewer krecipes kvirc python-pyside qlandkartegt qt4pas wkhtmltopdf amarok k3b python-pyqt4 qtscriptgenerator So +1 to both, I'm all for dropping unmaintained stuff. As for the webkitgtk list: pan is built without webkit support now.
On 2017-01-18 23:42, Jan Alexander Steffens via arch-dev-public wrote:
Thoughts?
I'm always happy to see packages dropped so go for it. (Also about gst0.10…) Bartłomiej
This list doesn't seem to cover (all) optional deps: My claws-mail pkg optdepends on webkitgtk2. I will rebuild it removing the html plugin. http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3710 -Andy
January 19, 2017 3:50 PM, "Andreas Radke" <andyrtr@archlinux.org> wrote:
This list doesn't seem to cover (all) optional deps:
My claws-mail pkg optdepends on webkitgtk2. I will rebuild it removing the html plugin.
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3710
-Andy
Removed the relevant plugins from cairo-dock and scratch-text-editor. I marked geary as complete without doing anything for now, it's in the process of being ported to webkit2gtk [0], but I don't think it's gonna be ready by the time we drop webkitgtk. It may have to get a temporary taste of AUR. [0] https://git.gnome.org/browse/geary/log/?h=wip/728002-webkit2 Cheers, -- Maxime
Le mercredi 18 janvier 2017, 22:42:38 CET Jan Alexander Steffens via arch-dev- public a écrit :
Hello list,
WebkitGTK+ 2.4 has been unmaintained for quite a while, and lots of CVEs have accumulated. The last release fixing CVEs, 2.4.10, only fixed about half the vulnerabilities known, and that release was only made because 2.4.9 was broken with GTK+ 3.20, and Evolution quickly needed a working HTML renderer.
And we are not alone, fedora and debian are planning the same: https://bugzilla.redhat.com/show_bug.cgi?id=1375843 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790216 An issue is already opened for uzbl [1], so i guess a move to aur is unavoidable ++ [1] https://github.com/uzbl/uzbl/issues/305 -- Laurent Carlier http://www.archlinux.org
To protect our users we should try to limit the packages using webkitgtk(2)., with the goal of eventually getting rid of it completely. I propose making a TODO that covers all these packages, with the following policy:
- If it can be updated to webkit2gtk, do so. - Otherwise, if WebKit is an optional dependency, build without it. - Otherwise, consider removing the package, especially if it's a browser.
Fedora is working on this too (with a deadline in mid-March), so this bug
On Wed, Jan 18, 2017 at 11:42 PM Jan Alexander Steffens < jan.steffens@gmail.com> wrote: tree might be of interest: https://bugzilla.redhat.com/showdependencytree.cgi?id=1375784
participants (9)
-
Andreas Radke
-
Antonio Rojas
-
Balló György
-
Bartłomiej Piotrowski
-
Gaetan Bisson
-
Jan Alexander Steffens
-
keenerd
-
Laurent Carlier
-
Maxime Gauduin