Re: Proposal: remove insecure WebKitGTK+ packages for F27

[Scott Talbert]

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

[Michael Catanzaro]

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

[Sérgio Basto]

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

[Scott Talbert]

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

[Sérgio Basto]

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
> 

Re: Proposal: remove insecure WebKitGTK+ packages for F27

[Kevin Kofler]

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

[Ben Boeckel]

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

[Michael Catanzaro]

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

[Ben Boeckel]

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

[Michael Catanzaro]

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

[Ben Boeckel]

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

[Kevin Fenzi]

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

[Milan Crha]

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

[Milan Crha]

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

[Christian Stadelmann]

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

[Igor Gnatenko]

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

[Scott Talbert]

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

[Michael Catanzaro]

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

[Michael Catanzaro]

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

[Michael Catanzaro]

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

[Richard W.M. Jones]

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

[Josh Boyer]

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

[Michael Catanzaro]

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

[Michael Catanzaro]

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

[Michael Catanzaro]

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