Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Thu, 22 Sep 2016, Michael Catanzaro wrote: Thanks for working on this Scott! On Thu, 2016-09-22 at 20:37 -0400, Scott Talbert wrote: Also, I plan to create a separate wxGTK3 subpackage containing the webview library that actually uses WebKit. That way, some of these artificial transitive dependencies on WebKit should go away. To be clear: that means any wxGTK3 app that does not use the web view widget will be perfectly safe, and that's probably 95% of them. OK, so I created a wxGTK3-webview subpackage containing the library that currently depends on webkitgtk3. I also created a similar wxPython-webview subpackage for the wxPython module. (I grepped the code of all wxPython-dependent packages and found none of them using the webview module, so there should be nothing to do with them.) After doing this, the number of packages recursively depending on webkitgtk3 went from 296 to 127! Scott___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
Thanks for working on this Scott! On Thu, 2016-09-22 at 20:37 -0400, Scott Talbert wrote: > Also, I plan to create a separate wxGTK3 subpackage containing the > webview > library that actually uses WebKit. That way, some of these > artificial > transitive dependencies on WebKit should go away. To be clear: that means any wxGTK3 app that does not use the web view widget will be perfectly safe, and that's probably 95% of them. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Qui, 2016-09-22 at 20:37 -0400, Scott Talbert wrote: > On Fri, 23 Sep 2016, Sérgio Basto wrote: > > > > > Hello , > > What is the status of this proposal ? or where/how I can follow the > > status ? > > My biggest concern is about wxGTK3 some package depend on it, also > > in > > 3rd part repos and gimp ! > I'm working on porting wxGTK3 to WebKit2. If you want, you can > follow the > upstream ticket: > http://trac.wxwidgets.org/ticket/17650 > > Also, I plan to create a separate wxGTK3 subpackage containing the > webview > library that actually uses WebKit. That way, some of these > artificial > transitive dependencies on WebKit should go away. Thanks. Off topic, I already found (webkit1-removal) Port applications to WebKit2 bug tracker https://bugzilla.redhat.com/show_bug.cgi?id=1375784 Best regards, -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Fri, 23 Sep 2016, Sérgio Basto wrote: Hello , What is the status of this proposal ? or where/how I can follow the status ? My biggest concern is about wxGTK3 some package depend on it, also in 3rd part repos and gimp ! I'm working on porting wxGTK3 to WebKit2. If you want, you can follow the upstream ticket: http://trac.wxwidgets.org/ticket/17650 Also, I plan to create a separate wxGTK3 subpackage containing the webview library that actually uses WebKit. That way, some of these artificial transitive dependencies on WebKit should go away. Scott___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Sex, 2016-06-10 at 08:11 -0500, Michael Catanzaro wrote: > Question: Where can I learn more? > > Answer: https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-secur > ity-updates/ > > > Question: What would be removed if this were to occur today? > > Answer: If you read this far, please seriously look over these lists. > Some big name applications are included. > > $ repoquery --whatrequires --recursive webkitgtk > > Yum-utils package has been deprecated, use dnf instead. > See 'man yum2dnf' for more information. > > > GREYCstoration-gimp-0:2.8-22.fc24.x86_64 > atril-0:1.14.1-1.fc24.x86_64 > atril-caja-0:1.14.1-1.fc24.x86_64 > atril-devel-0:1.14.1-1.fc24.i686 > atril-devel-0:1.14.1-1.fc24.x86_64 > atril-libs-0:1.14.1-1.fc24.i686 > atril-libs-0:1.14.1-1.fc24.x86_64 > atril-thumbnailer-0:1.14.1-1.fc24.x86_64 > banshee-0:2.6.2-15.fc24.x86_64 > banshee-community-extensions-0:2.4.0-14.fc24.x86_64 > banshee-devel-0:2.6.2-15.fc24.i686 > banshee-devel-0:2.6.2-15.fc24.x86_64 > billiards-0:0.4.1-10.fc24.x86_64 > claws-mail-plugins-0:3.13.2-2.fc24.x86_64 > claws-mail-plugins-fancy-0:3.13.2-2.fc24.x86_64 > compat-wxGTK3-gtk2-0:3.0.2-7.fc24.i686 > compat-wxGTK3-gtk2-0:3.0.2-7.fc24.x86_64 > compat-wxGTK3-gtk2-devel-0:3.0.2-7.fc24.i686 > compat-wxGTK3-gtk2-devel-0:3.0.2-7.fc24.x86_64 > compat-wxGTK3-gtk2-docs-0:3.0.2-7.fc24.noarch > compat-wxGTK3-gtk2-gl-0:3.0.2-7.fc24.i686 > compat-wxGTK3-gtk2-gl-0:3.0.2-7.fc24.x86_64 > compat-wxGTK3-gtk2-media-0:3.0.2-7.fc24.i686 > compat-wxGTK3-gtk2-media-0:3.0.2-7.fc24.x86_64 > conduit-0:0.3.17-12.fc24.noarch > dissy-0:10-5.fc24.noarch > fityk-0:1.3.0-8.fc24.i686 > fityk-0:1.3.0-8.fc24.x86_64 > fityk-devel-0:1.3.0-8.fc24.i686 > fityk-devel-0:1.3.0-8.fc24.x86_64 > gap-pkg-alnuth-0:3.0.0-6.fc24.noarch > gap-pkg-cryst-0:4.1.12-4.fc24.noarch > gap-pkg-crystcat-0:1.1.6-4.fc24.noarch > gap-pkg-nq-0:2.5.3-1.fc24.x86_64 > gap-pkg-polenta-0:1.3.6-1.fc24.noarch > gap-pkg-polycyclic-0:2.11-6.fc24.noarch > gap-pkg-radiroot-0:2.7-5.fc24.noarch > geany-plugins-devhelp-0:1.27-1.fc24.x86_64 > geany-plugins-geanypy-0:1.27-1.fc24.x86_64 > geany-plugins-markdown-0:1.27-1.fc24.x86_64 > geany-plugins-webhelper-0:1.27-1.fc24.x86_64 > ghc-webkit-0:0.14.1.1-1.fc24.x86_64 > ghc-webkit-devel-0:0.14.1.1-1.fc24.x86_64 > gimp-2:2.8.16-1.fc24.1.x86_64 > gimp-data-extras-0:2.0.2-13.fc24.noarch > gimp-dbp-0:1.1.9-9.fc24.x86_64 > gimp-dds-plugin-0:3.0.1-5.fc24.x86_64 > gimp-elsamuko-0:26-2.fc24.noarch > gimp-fourier-plugin-0:0.4.1-12.fc24.x86_64 > gimp-gap-0:2.7.0-14.GITe75bd46.fc24.x86_64 > gimp-help-0:2.8.2-5.fc24.noarch > gimp-help-browser-2:2.8.16-1.fc24.1.x86_64 > gimp-help-ca-0:2.8.2-5.fc24.noarch > gimp-help-da-0:2.8.2-5.fc24.noarch > gimp-help-de-0:2.8.2-5.fc24.noarch > gimp-help-el-0:2.8.2-5.fc24.noarch > gimp-help-en_GB-0:2.8.2-5.fc24.noarch > gimp-help-es-0:2.8.2-5.fc24.noarch > gimp-help-fr-0:2.8.2-5.fc24.noarch > gimp-help-it-0:2.8.2-5.fc24.noarch > gimp-help-ja-0:2.8.2-5.fc24.noarch > gimp-help-ko-0:2.8.2-5.fc24.noarch > gimp-help-nl-0:2.8.2-5.fc24.noarch > gimp-help-nn-0:2.8.2-5.fc24.noarch > gimp-help-pt_BR-0:2.8.2-5.fc24.noarch > gimp-help-ru-0:2.8.2-5.fc24.noarch > gimp-help-sl-0:2.8.2-5.fc24.noarch > gimp-help-sv-0:2.8.2-5.fc24.noarch > gimp-help-zh_CN-0:2.8.2-5.fc24.noarch > gimp-high-pass-filter-0:1.2-6.fc24.noarch > gimp-lqr-plugin-0:0.7.2-4.fc24.x86_64 > gimp-normalmap-0:1.2.3-12.fc24.x86_64 > gimp-paint-studio-0:2.0-11.fc24.noarch > gimp-resynthesizer-0:0.16-14.fc24.x86_64 > gimp-save-for-web-0:0.29.3-1.fc24.x86_64 > gimp-separate+-0:0.5.8-16.fc24.x86_64 > gimp-wavelet-denoise-plugin-0:0.3.1-9.fc24.x86_64 > gimpfx-foundry-0:2.6.1-5.fc24.noarch > gmpc-0:11.8.16-11.fc24.x86_64 > gmpc-devel-0:11.8.16-11.fc24.i686 > gmpc-devel-0:11.8.16-11.fc24.x86_64 > gmusicbrowser-0:1.1.15-2.fc24.noarch > gnucash-0:2.6.12-1.fc24.i686 > gnucash-0:2.6.12-1.fc24.x86_64 > gphpedit-0:0.9.98-0.11.RC1.fc24.x86_64 > gpodder-0:3.9.0-1.fc24.noarch > gscribble-0:0.1.2-10.fc24.noarch > gtk-sharp-beans-0:2.14.0-17.fc24.x86_64 > gtk-sharp-beans-devel-0:2.14.0-17.fc24.i686 > gtk-sharp-beans-devel-0:2.14.0-17.fc24.x86_64 > guitarix-0:0.35.0-2.fc24.x86_64 > gutenprint-plugin-0:5.2.11-2.fc24.x86_64 > gyachi-0:1.2.11-14.fc24.x86_64 > gyachi-YMlike-theme-0:1.2.11-14.fc24.x86_64 > gyachi-pidgy-theme-0:1.2.11-14.fc24.x86_64 > gyachi-plugin-alsa-0:1.2.11-14.fc24.x86_64 > gyachi-plugin-blowfish-0:1.2.11-14.fc24.x86_64 > gyachi-plugin-gtkspell-0:1.2.11-14.fc24.x86_64 > gyachi-plugin-libnotify-0:1.2.11-14.fc24.x86_64 > gyachi-plugin-mcrypt-0:1.2.11-14.fc24.x86_64 > gyachi-plugin-pulseaudio-0:1.2.11-14.fc24.x86_64 > gyachi-recre8-theme-0:1.2.11-14.fc24.x86_64 > icaro-0:1.0.4-3.fc24.noarch > kazehakase-0:0.5.8-20.svn3873_trunk.fc24.1.x86_64 > kazehakase-webkit-0:0.5.8-20.svn3873_trunk.fc24.1.x86_64 > kicad-1:4.0.2-2.fc24.x86_64 > lekhonee-gnome-0:0.12-9.fc24.x86_64 > lv2-guitarix-plugins-0:0.35.0-2.fc24.x86_64 > midori-0:0.5.11-2.fc24.i686 > midori-0:0.5.11-2.fc24.x86_64 > mono-tools-0:4.2-2.fc24.x86_64 > mono-tools-devel-0:
Re: Proposal: remove insecure WebKitGTK+ packages for F27
Michael Catanzaro wrote: > I propose we retire the webkitgtk and webkitgtk3 packages when > branching rawhide for F26 (expected to occur roughly February 2017), > and forbid unretiring them. All their dependencies would then be > removed from from Fedora according to the normal process shortly before > the release of F27 (excepted to occur May 2017). If nobody objects, > we'll carry out this plan shortly after the F26 branch point. Looking at the terabazillion affected packages, this will be a trainwreck! For QtWebKit, everyone was saying that it is impossible to keep supporting the old API. Then someone came and just did it. IMHO, this is the only practicable solution for WebKitGTK as well. Well, that or port all the applications in the list. There are some extremely-high-profile applications in your list of affected packages: GIMP, SAGE (sagemath), Audacity, etc., and even GNOME Shell! (Now *I* wouldn't complain if GNOME Shell were removed from Fedora, but… ;-) ) So removing all those packages from Fedora, and even effectively forbidding them from being readded, is not practicable. > Answer: If you're sure your application never processes untrusted > input, it is a special flower. You should request a bundling exception > from FESCo if you do not intend to upgrade. So you want to replace one copy of vulnerable code by many copies of vulnerable code? How is that going to help any? It would also severely bloat the distribution, given the huge size of WebKit. This is just totally impractical. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Wed, Jun 15, 2016 at 19:24:35 -0500, Michael Catanzaro wrote: > The reason we don't offer a sync API is that it could cause your > application to hang during IPC between the browser process and the web > process. Understood. It's one of the reasons we're looking at getting the "uzbl" bits separate from the "gui" bits. Unfortunately, there's lots of crosstalk (accessing GTK objects from the other thread is fraught with peril as one would expect) and C is not exactly the most…expressive language for such things. --Ben -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Wed, 2016-06-15 at 19:50 -0400, Ben Boeckel wrote: > That works if you can deal with the result being asynchronous, but if > your callback doesn't belong in the GUI thread… Ah, I think this arose from the discussion about disabling/enabling context menu items. [1] is related. The reason we don't offer a sync API is that it could cause your application to hang during IPC between the browser process and the web process. [1] https://bugzilla.gnome.org/show_bug.cgi?id=765145 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Wed, Jun 15, 2016 at 18:23:00 -0500, Michael Catanzaro wrote: > On Wed, 2016-06-15 at 22:26 +, Ben Boeckel wrote: > > Note that running JavaScript code in the context of the webpage also > > requires an extension (AFAICS). > > Fortunately, you can actually do this from the UI process using > webkit_web_view_run_javascript() and > webkit_web_view_run_javascript_finish(). > > [1] > http://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebView.html#webkit-web-view-run-javascript That works if you can deal with the result being asynchronous, but if your callback doesn't belong in the GUI thread… --Ben -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Wed, 2016-06-15 at 22:26 +, Ben Boeckel wrote: > Note that running JavaScript code in the context of the webpage also > requires an extension (AFAICS). Fortunately, you can actually do this from the UI process using webkit_web_view_run_javascript() and webkit_web_view_run_javascript_finish(). [1] http://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebView.html#webkit-web-view-run-javascript -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Fri, 10 Jun, 2016 at 16:39:21 GMT, Michael Catanzaro wrote: > If your app does use the DOM API, you have more work as you need to > create a web process extension to access this API. You can use any form > of IPC to communicate between the UI process and the web process; D-Bus > is a good option. Documentation here: Note that running JavaScript code in the context of the webpage also requires an extension (AFAICS). --Ben -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Sun, 12 Jun 2016 11:28:00 - "Christian Stadelmann" wrote: > I like this idea very much, thank you! > > Independent to whether this proposal is accepted or not, I'd like to > point out that it would be very useful to notify all maintainers of > this issue, probably by filing a bug to every package that uses one > of these packages (webkitgtk, webkitgtk3), adding a link to your > statement above and tell the maintainer to take action: Contact > upstream. If upstream will be porting the package to Webkit2Gtk, ship > it in Fedora. If not, try to build without WebKit support. If that > fails, deprecate a package by filing bugs to all packages relying on > it. > > Sadly, I don't know any way to automate this and filing ~50 bugs is > quite much. I'll note that if someone is going to do this, please read and follow https://fedoraproject.org/wiki/Mass_bug_filing Thanks. kevin pgp5xcho49IBC.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Fri, 2016-06-10 at 08:11 -0500, Michael Catanzaro wrote: > Active porting efforts are underway for Evolution (which will take > care of the mass of evolution-data-server dependencies like gnome- > shell and gdm) Hi, I think it's a very important detail, because if I remove the --recursive argument in your repoquery command, then I get significantly shorter list of affected packages [1], with ~half of them being addressed by the ongoing effort for the Evolution port. At least in case of the evolution-data-server, it uses the WebKit1, but doesn't expose it in the public API, thus it's a private dependency, spread on its own "users" only through the linker (libraries). I mean, checking only for direct dependencies makes more sense, from my point of view. Bye, Milan [1] repoquery --whatrequires webkitgtk3 --enablerepo=updates-testing Yum-utils package has been deprecated, use dnf instead. See 'man yum2dnf' for more information. balsa-0:2.5.2-3.fc24.x86_64 bijiben-0:3.20.2-1.fc24.x86_64 cairo-dock-plug-ins-webkit-0:3.4.1-7.fc24.x86_64 dwb-0:2015.10.09-2.20151009git.fc24.x86_64 emacs-1:25.0.94-1.fc24.x86_64 empathy-0:3.12.12-1.fc24.x86_64 evolution-0:3.20.2-1.fc24.i686 evolution-0:3.20.2-1.fc24.x86_64 evolution-0:3.20.3-1.fc24.i686 evolution-0:3.20.3-1.fc24.x86_64 evolution-bogofilter-0:3.20.2-1.fc24.x86_64 evolution-bogofilter-0:3.20.3-1.fc24.x86_64 evolution-data-server-0:3.20.2-1.fc24.i686 evolution-data-server-0:3.20.2-1.fc24.x86_64 evolution-data-server-0:3.20.3-1.fc24.i686 evolution-data-server-0:3.20.3-1.fc24.x86_64 evolution-data-server-tests-0:3.20.2-1.fc24.i686 evolution-data-server-tests-0:3.20.2-1.fc24.x86_64 evolution-data-server-tests-0:3.20.3-1.fc24.i686 evolution-data-server-tests-0:3.20.3-1.fc24.x86_64 evolution-ews-0:3.20.2-1.fc24.i686 evolution-ews-0:3.20.2-1.fc24.x86_64 evolution-ews-0:3.20.3-1.fc24.x86_64 evolution-mapi-0:3.20.1-1.fc24.i686 evolution-mapi-0:3.20.1-1.fc24.x86_64 evolution-mapi-0:3.20.3-1.fc24.i686 evolution-mapi-0:3.20.3-1.fc24.x86_64 evolution-pst-0:3.20.2-1.fc24.x86_64 evolution-pst-0:3.20.3-1.fc24.x86_64 evolution-rss-1:0.3.95-7.fc24.x86_64 evolution-spamassassin-0:3.20.2-1.fc24.x86_64 evolution-spamassassin-0:3.20.3-1.fc24.x86_64 geary-0:0.11.0-1.fc24.x86_64 gnome-web-photo-0:0.10.5-9.fc24.x86_64 gphotoframe-0:2.0.2-2.hg2084299dffb6.fc24.1.noarch liferea-1:1.10.19-1.fc24.x86_64 rubygem-webkit-gtk-0:3.0.8-1.fc24.noarch seed-0:3.8.1-7.fc24.i686 seed-0:3.8.1-7.fc24.x86_64 sugar-browse-0:157.3-1.fc24.noarch surf-0:0.7-1.fc24.x86_64 uzbl-core-0:0-0.39.20120514git228bc38cbd.fc24.x86_64 vfrnav-0:20160212-3.fc24.i686 vfrnav-0:20160212-3.fc24.x86_64 webkitgtk3-devel-0:2.4.11-1.fc24.i686 webkitgtk3-devel-0:2.4.11-1.fc24.x86_64 webkitgtk3-doc-0:2.4.11-1.fc24.noarch wxGTK3-0:3.0.2-19.fc24.i686 wxGTK3-0:3.0.2-19.fc24.x86_64 xiphos-gtk3-0:4.0.4-3.fc24.x86_64 xiphos-gtk3-0:4.0.4-4.fc24.x86_64 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Fri, 2016-06-10 at 11:39 -0500, Michael Catanzaro wrote: > There's no transition documentation. Basically, you want to make sure > your package builds when switching the pkg-config version in > configure.ac to webkit2gtk-4.0. Hi, feel free to check out what the evolution-data-server does to switch from WebKit1 to WebKit2 here [1]. The code only opens a page and finally reads its title with a result, listening for a signal when the page was loaded. It doesn't do any DOM operations on the page. Bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=751588#c22 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
I like this idea very much, thank you! Independent to whether this proposal is accepted or not, I'd like to point out that it would be very useful to notify all maintainers of this issue, probably by filing a bug to every package that uses one of these packages (webkitgtk, webkitgtk3), adding a link to your statement above and tell the maintainer to take action: Contact upstream. If upstream will be porting the package to Webkit2Gtk, ship it in Fedora. If not, try to build without WebKit support. If that fails, deprecate a package by filing bugs to all packages relying on it. Sadly, I don't know any way to automate this and filing ~50 bugs is quite much. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Jun 10, 2016 8:32 PM, "Scott Talbert" wrote: > > On Fri, 10 Jun 2016, Michael Catanzaro wrote: > >> Question: What if my application depends on GTK+ 2? >> >> Answer: You must first port to GTK+ 3, then port to WebKit2. You may >> find it more practical to stop using WebKitGTK+. > > > What is the WebKit2 package in Fedora? Is that webkitgtk4? Yes. > > Scott > > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Fri, 10 Jun 2016, Michael Catanzaro wrote: Question: What if my application depends on GTK+ 2? Answer: You must first port to GTK+ 3, then port to WebKit2. You may find it more practical to stop using WebKitGTK+. What is the WebKit2 package in Fedora? Is that webkitgtk4? Scott -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Fri, 2016-06-10 at 08:11 -0500, Michael Catanzaro wrote: > Answer: QtWebKit has not had security updates since ~2012 The QtWebKit folks asked me to point out that they were merging security fixes until 2014. More information is available at [1]; you can judge the situation for yourself. [1] http://trac.webkit.org/wiki/QtWebKitSecurity -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Fri, 2016-06-10 at 15:02 +0100, Richard W.M. Jones wrote: > What do we actually have to do to move apps that are using the > Webkit API to the new version? What code changes are needed? > Is there documentation for this? There's no transition documentation. Basically, you want to make sure your package builds when switching the pkg-config version in configure.ac to webkit2gtk-4.0. There is API documentation here: http://webkitgtk.org/reference/webkit2gtk/stable/ Stable DOM (web process) API: http://webkitgtk.org/reference/webkitdomgtk/stable/ Deprecated API (what you are porting away from): http://webkitgtk.org/reference/webkitgtk/stable/index.html If your app doesn't use the DOM API, the port should be straightforward. Your app will probably work once you manage to compile it. Be sure to check if any signals you connect to have been renamed. If your app does use the DOM API, you have more work as you need to create a web process extension to access this API. You can use any form of IPC to communicate between the UI process and the web process; D-Bus is a good option. Documentation here: http://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebExtension.html Epiphany serves as a good (if complex) example of how to write a web extension: https://git.gnome.org/browse/epiphany/tree/embed/web-extension Hope that helps a bit... happy to answer more questions. Michael -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Fri, 2016-06-10 at 09:58 -0400, Josh Boyer wrote: > > > I am all for anything that removes emacs from our distribution. How > can I help ensure this happens? > > Serious answer: the Emacs dependency on unsupported WebKit was added two months ago and can be avoided by changing a configure flag: http://pkgs.fedoraproject.org/cgit/rpms/emacs.git/commit/?id=27d3963a4bee39a7a1b6fb6ff064e23030339211 So fortunately it's not too serious of a problem. There are other apps on that list that can be "ported" with a configure flag change as well. E.g. GIMP only uses WebKit for its help center; we should disable that so that user help opens in the user's default browser instead. Removing these old WebKit packages would help avoid introducing such issues when maintainers do not realize that webkitgtk3 is unsupported and insecure. Michael -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
What do we actually have to do to move apps that are using the Webkit API to the new version? What code changes are needed? Is there documentation for this? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Fri, Jun 10, 2016 at 9:11 AM, Michael Catanzaro wrote: > Hi, > > I propose we retire the webkitgtk and webkitgtk3 packages when > branching rawhide for F26 (expected to occur roughly February 2017), > and forbid unretiring them. All their dependencies would then be > removed from from Fedora according to the normal process shortly before > the release of F27 (excepted to occur May 2017). If nobody objects, > we'll carry out this plan shortly after the F26 branch point. > emacs-1:25.0.94-1.fc24.x86_64 I am all for anything that removes emacs from our distribution. How can I help ensure this happens? josh -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Fri, 2016-06-10 at 08:11 -0500, Michael Catanzaro wrote: > I propose we retire the webkitgtk and webkitgtk3 packages when > branching rawhide for F26 (expected to occur roughly February 2017), > and forbid unretiring them. All their dependencies would then be > removed from from Fedora according to the normal process shortly > before > the release of F27 (excepted to occur May 2017). If nobody objects, > we'll carry out this plan shortly after the F26 branch point. Let me try this one more time, as the dates I have here are wrong/inconsistent. * Branch F26 from rawhide around January 2017. * F26 release around May 2017. * Branch F27 from rawhide around July 2017. * F27 release around November 2017. We can use either set of dates. I'm inclined to go with the earlier dates. The benefit of using later dates is it would allow more time for GTK+ 2 apps to port to GTK+ 3, but I don't honestly expect pushing the dates later would make a difference in which applications get ported in time. Michael -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Fri, 2016-06-10 at 08:11 -0500, Michael Catanzaro wrote: > I propose we retire the webkitgtk and webkitgtk3 packages when > branching rawhide for F26 (expected to occur roughly February 2017) To clarify: I propose removing the packages from rawhide (only) shortly after branching for F26, that way nothing will be removed until F27. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Proposal: remove insecure WebKitGTK+ packages for F27
Hi, I propose we retire the webkitgtk and webkitgtk3 packages when branching rawhide for F26 (expected to occur roughly February 2017), and forbid unretiring them. All their dependencies would then be removed from from Fedora according to the normal process shortly before the release of F27 (excepted to occur May 2017). If nobody objects, we'll carry out this plan shortly after the F26 branch point. Question: Why retire these packages? Answer: Affected applications that process untrusted input are vulnerable to roughly 150 unfixed security vulnerabilities, the overwhelming majority of which are remote code execution vulnerabilities. The severity of this situation arguably outweighs the benefit of keeping affected applications around. Question: This sounds horrible, we should act soon. Why wait until F26? Answer: Porting to the new WebKitGTK+ API is easy for many applications, but for applications that use the DOM API it can be expected to take some time, as this API has moved to the web process and accessing it requires writing a web process extension. If we were to use F25 as the deadline, there would not be sufficient time for applications to be ported. Porting efforts should begin as soon as possible. Question: What if my application doesn't process untrusted input? Answer: If you're sure your application never processes untrusted input, it is a special flower. You should request a bundling exception from FESCo if you do not intend to upgrade. Question: You're horrible for proposing to remove my packages. Answer: WebKit1 was deprecated in March 2013. Packages have had three years to upgrade. It's clear at this point that this problem won't ever be fixed without a hard deadline that is enforced. But this is a fair point; it sucks a lot that compatibility is not offered here. Such is the cost of free software Question: We usually allow compatibility libraries to exist indefinitely. Why so strict with WebKit? Answer: Our compatibility libraries do not usually have upwards of 150 unfixed remote code execution vulnerabilities. Backporting fixes is not practical in this situation. Question: But these packages are still included in RHEL. Isn't Red Hat providing security updates? Answer: No. Question: Will you help port my packages to newer WebKit? Answer: We'll answer questions, but unfortunately we can only provide serious assistance to priority GNOME packages. evolution-data-server threatens to take out gnome-shell if removed, for instance, which is why we waited until the Evolution port is nearing completion to propose this. Question: What if my application depends on GTK+ 2? Answer: You must first port to GTK+ 3, then port to WebKit2. You may find it more practical to stop using WebKitGTK+. Question: What if my application needs to work on Windows? Answer: WebKit2 is not supported on Windows. You will need to either commit to developing Windows support, or stop using WebKitGTK+. Question: I hear QtWebKit is insecure too, why punish only GTK+ apps? Answer: QtWebKit has not had security updates since ~2012 and so has even more unfixed vulnerabilities. However, an unofficial effort is underway to rebase QtWebKit on the upstream WebKit project. The plan is to make regular QtWebKit releases based on the latest WebKitGTK+ stable branch, meaning there should be regular security updates. This is still a work in progress, but once completed, Fedora will be able to switch upstreams and solve this issue without the need to port applications to QtWebEngine. No such compatibility effort is planned for WebKitGTK+. Question: Where can I view WebKitGTK+ security advisories? Answer: http://webkitgtk.org/security.html Question: Where can I learn more? Answer: https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/ Question: What would be removed if this were to occur today? Answer: If you read this far, please seriously look over these lists. Some big name applications are included. $ repoquery --whatrequires --recursive webkitgtk Yum-utils package has been deprecated, use dnf instead. See 'man yum2dnf' for more information. GREYCstoration-gimp-0:2.8-22.fc24.x86_64 atril-0:1.14.1-1.fc24.x86_64 atril-caja-0:1.14.1-1.fc24.x86_64 atril-devel-0:1.14.1-1.fc24.i686 atril-devel-0:1.14.1-1.fc24.x86_64 atril-libs-0:1.14.1-1.fc24.i686 atril-libs-0:1.14.1-1.fc24.x86_64 atril-thumbnailer-0:1.14.1-1.fc24.x86_64 banshee-0:2.6.2-15.fc24.x86_64 banshee-community-extensions-0:2.4.0-14.fc24.x86_64 banshee-devel-0:2.6.2-15.fc24.i686 banshee-devel-0:2.6.2-15.fc24.x86_64 billiards-0:0.4.1-10.fc24.x86_64 claws-mail-plugins-0:3.13.2-2.fc24.x86_64 claws-mail-plugins-fancy-0:3.13.2-2.fc24.x86_64 compat-wxGTK3-gtk2-0:3.0.2-7.fc24.i686 compat-wxGTK3-gtk2-0:3.0.2-7.fc24.x86_64 compat-wxGTK3-gtk2-devel-0:3.0.2-7.fc24.i686 compat-wxGTK3-gtk2-devel-0:3.0.2-7.fc24.x86_64 compat-wxGTK3-gtk2-docs-0:3.0.2-7.fc24.noarch compat-wxGTK3-gtk2-gl-0:3.0.2-7.fc24.i686 compat-wxGTK3-gtk2-gl-0:3.0.2-7