Re: Browser choice in live images

[Kevin Kofler]

Michael Catanzaro wrote:
> I miss QtWebKit. :(
> 
> For those not familiar with the history, QtWebKit was deleted from the
> upstream WebKit project about three years ago after the maintainers
> said they no longer had the resources to continue maintaining it
> upstream. It now lives on KDE.org but it's based on an ancient WebKit
> revision.

It actually lives at qt.io, and is deprecated there. Qt 5.5 is the last 
release series that includes it. Qt 5.6 will no longer include it in the 
tarballs. (We will likely keep QtWebKit 5.5 or a git snapshot available, 
similarly to how this is done with webkitgtk 2.4, but security updates will 
be limited to what we can backport ourselves.)

The situation for Konqueror is even worse because it is stuck on Qt 4 (but 
then again, the Qt 5 QtWebKit is not significantly more modern than the Qt 4 
one (we ship the unofficial "QtWebKit 2.3" release branch for Qt 4, which 
matches what early Qt 5 shipped)).

> I don't know what the security story is there, but I imagine
> not good, and I guess that's why you switched to Firefox?

The reasons they switched (I was against it) include that, and compatibility 
with some websites. The big issue is that Firefox does not integrate at all 
into KDE Plasma. I think Fedora KDE should really have sat out that one 
release cycle on Konqueror and targeted QtWebEngine for F24.

> Now bundling is allowed, you can bring in QtWebEngine, and try porting
> Rekonq to use that. It's sad to be forced to switch to Chromium
> bundleland, but Chromium works well and comes with a top-class sandbox,
> so Rekonq would immediately become about 3252389724x more secure than
> Firefox or Epiphany. Unless you're willing to use QtWebEngine, I see no
> future for Qt-based web browsers. :/

QtWebEngine is definitely the plan for F24. The most likely browser 
candidate (if Konqueror and/or Rekonq don't get a sudden revival of upstream 
activity) is probably Qupzilla, which already has experimental QtWebEngine 
support, and which has some amount of KDE integration. (It uses Qt, it 
should get KDE file dialogs through the KDE/Plasma Qt platform plugin, it 
explicitly supports KWallet through the QtKeychain abstraction.)

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Michael Catanzaro]

On Fri, 2015-11-06 at 20:07 +0100, Kevin Kofler wrote:
> QtWebEngine is definitely the plan for F24. The most likely browser 
> candidate (if Konqueror and/or Rekonq don't get a sudden revival of
> upstream 
> activity) is probably Qupzilla, which already has experimental
> QtWebEngine 
> support, and which has some amount of KDE integration. (It uses Qt,
> it 
> should get KDE file dialogs through the KDE/Plasma Qt platform
> plugin, it 
> explicitly supports KWallet through the QtKeychain abstraction.)

Best of luck with this. It's important to have a well-integrated web
browser based on a modern rendering engine. I expect you'll have that in the 
KDE spin before we do in Workstation.

Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Kevin Kofler]

Michael Catanzaro wrote:

> On Fri, 2015-11-06 at 20:07 +0100, Kevin Kofler wrote:
>> QtWebEngine is definitely the plan for F24. The most likely browser
>> candidate (if Konqueror and/or Rekonq don't get a sudden revival of
>> upstream
>> activity) is probably Qupzilla, which already has experimental
>> QtWebEngine
>> support, and which has some amount of KDE integration. (It uses Qt,
>> it
>> should get KDE file dialogs through the KDE/Plasma Qt platform
>> plugin, it
>> explicitly supports KWallet through the QtKeychain abstraction.)
> 
> Best of luck with this. It's important to have a well-integrated web
> browser based on a modern rendering engine. I expect you'll have that in
> the KDE spin before we do in Workstation.

I suspect Qupzilla might actually feel more integrated into GNOME than 
Firefox. You have the Adwaita-Qt theme, the Qt platform plugin system 
supports GTK+ file dialogs, QtKeychain supports gnome-keyring, and Qupzilla 
should also pick up GNOME's fd.o icon theme unlike Firefox.

You could try it with the version we currently have, but beware that it's 
still a QtWebKit version, not the shiny new QtWebEngine stuff. (By the way, 
QtWebEngine support in Qupzilla is apparently no longer experimental. So 
it's just a matter of packaging now.)

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Kevin Kofler]

Two small corrections about Qupzilla:

I wrote:
> QtWebEngine is definitely the plan for F24. The most likely browser
> candidate (if Konqueror and/or Rekonq don't get a sudden revival of
> upstream activity) is probably Qupzilla, which already has experimental
> QtWebEngine support, and which has some amount of KDE integration. (It

As I pointed out elsewhere in the thread, QtWebEngine support is actually no 
longer experimental, and the current versions are QtWebEngine-only.

> uses Qt, it should get KDE file dialogs through the KDE/Plasma Qt platform
> plugin, it explicitly supports KWallet through the QtKeychain
> abstraction.)

I checked the code and Qupzilla does not use the QtKeychain library, it has 
its own plugin system for that, but yes, it supports both KWallet and
gnome-keyring.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Bastien Nocera]

- Original Message -
> On Thu, 2015-11-05 at 09:53 -0600, Michael Catanzaro wrote:
> > On Thu, 2015-11-05 at 16:21 +0100, Jos Vos wrote:
> > > I see that the F23 Xfce live image still includes only Midori as the
> > > internet browser, similar to the F22 image.
> > 
> > Midori still depends on an old version of WebKitGTK+, so it has not had
> > any security updates in a long time. It's irresponsible to ship it
> > until this is fixed.
> 
> WebKitGTK+ 2.4.9 was shipped in May, and 2.4.8 before that in January
> with a bunch of security fixes, all despite the fact that they had since
> released 2.6.x and 2.8.x.  This tells me that the 2.4 branch, while
> deprecated, continues to be maintained.

Michael is an upstream WebKitGTK+ developer, he'd know.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Kevin Fenzi]

On Thu, 05 Nov 2015 10:22:23 -0600
Yaakov Selkowitz  wrote:

> On Thu, 2015-11-05 at 09:53 -0600, Michael Catanzaro wrote:
> > On Thu, 2015-11-05 at 16:21 +0100, Jos Vos wrote:  
> > > I see that the F23 Xfce live image still includes only Midori as
> > > the internet browser, similar to the F22 image.  
> > 
> > Midori still depends on an old version of WebKitGTK+, so it has not
> > had any security updates in a long time. It's irresponsible to ship
> > it until this is fixed.  
> 
> WebKitGTK+ 2.4.9 was shipped in May, and 2.4.8 before that in January
> with a bunch of security fixes, all despite the fact that they had
> since released 2.6.x and 2.8.x.  This tells me that the 2.4 branch,
> while deprecated, continues to be maintained.

So, in no particular order: 

* I don't really think it's 'irresponsible' to ship midori in it's
  current state. It's not ideal, but if you know of specific critical
  issues not fixed, please let me know. 

* Midori upstream is working on moving to webkit2 (for quite a while
  now). They have the base browser pretty much done, but they still are
  working on porting some of the plugins. They keep hoping to switch
  defaults soon, but they are a small project and have as much time as
  they have. Any assistance with porting I'm sure would be welcome. 

* All that said, the reason for not shipping firefox was that we were
  trying to keep under cd size. Since we gave up on that a few releases
  back, I have no objection to re-adding firefox on the Xfce spin.
  (which I have just done)

kevin



pgphboozICnP5.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Yaakov Selkowitz]

On Thu, 2015-11-05 at 09:53 -0600, Michael Catanzaro wrote:
> On Thu, 2015-11-05 at 16:21 +0100, Jos Vos wrote:
> > I see that the F23 Xfce live image still includes only Midori as the
> > internet browser, similar to the F22 image.
> 
> Midori still depends on an old version of WebKitGTK+, so it has not had
> any security updates in a long time. It's irresponsible to ship it
> until this is fixed.

WebKitGTK+ 2.4.9 was shipped in May, and 2.4.8 before that in January
with a bunch of security fixes, all despite the fact that they had since
released 2.6.x and 2.8.x.  This tells me that the 2.4 branch, while
deprecated, continues to be maintained.

-- 
Yaakov Selkowitz
Associate Software Engineer, ARM
Red Hat, Inc.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Dan Book]

On Thu, Nov 5, 2015 at 11:35 AM, Kevin Kofler 
wrote:

> Jos Vos wrote:
> > I see that the F23 Xfce live image still includes only Midori as the
> > internet browser, similar to the F22 image.
>
> At least one image that is still consistent with its goals in its
> application choice. The KDE image is now polluted by Firefox, which sticks
> out like a sore thumb. :-(
>
> Kevin Kofler
>


There is sadly an ever shrinking list of web browsers which are both
feature-complete and open-source, and the other one has bundling problems.


> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Michael Catanzaro]

On Thu, 2015-11-05 at 10:22 -0600, Yaakov Selkowitz wrote:
> On Thu, 2015-11-05 at 09:53 -0600, Michael Catanzaro wrote:
> > On Thu, 2015-11-05 at 16:21 +0100, Jos Vos wrote:
> > > I see that the F23 Xfce live image still includes only Midori as
> > > the
> > > internet browser, similar to the F22 image.
> > 
> > Midori still depends on an old version of WebKitGTK+, so it has not
> > had
> > any security updates in a long time. It's irresponsible to ship it
> > until this is fixed.
> 
> WebKitGTK+ 2.4.9 was shipped in May, and 2.4.8 before that in January
> with a bunch of security fixes, all despite the fact that they had
> since
> released 2.6.x and 2.8.x.  This tells me that the 2.4 branch, while
> deprecated, continues to be maintained.

Note: The 2.4 branch was the last branch that contained the WebKit1
API; that's why we still have it in Fedora and why apps still use it.
It's a compatibility package.

2.4.9 was probably the last 2.4 release (at least we have no commitment
or plan to do further releases); the goal of that release was to fix
the Windows build, since Windows support was removed in 2.6, and
Windows users were needing several downstream patches to build 2.4.8.
The 2.4.9 release had maybe one or two security fixes that happened to
be easy to backport. The real security support ended in January with
the 2.4.8 release.

It would be quite unlikely to see any further security updates for the
2.8 branch (in F22), let alone 2.6 (in F21) or 2.4, though we
informally consider 2.8 to still be supported. I am very concerned
about keeping old releases of WebKit in supported Fedora releases; the
reason we do that is that the updates have an unusually-high chance of
regressions, but web engines are special and I think that does not
outweigh the cost of not getting security updates.

Note that these security updates are quite complicated to backport, so
if there is no upstream release, the fixes will not arrive in Fedora;
there aren't 2.4 releases anymore due to the complexity of the
backports.

Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Kevin Kofler]

Jos Vos wrote:
> I see that the F23 Xfce live image still includes only Midori as the
> internet browser, similar to the F22 image.

At least one image that is still consistent with its goals in its 
application choice. The KDE image is now polluted by Firefox, which sticks 
out like a sore thumb. :-(

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Michael Catanzaro]

On Thu, 2015-11-05 at 12:23 -0600, Michael Catanzaro wrote:
> September: 34 bugs with impact "Visiting a maliciously crafted
> website
> may lead to an unexpected application termination or arbitrary code
> execution" https://support.apple.com/en-us/HT205377

Corrected link: https://support.apple.com/en-us/HT205265

More from this year:

https://support.apple.com/kb/HT205033
https://support.apple.com/kb/HT204950
https://support.apple.com/kb/HT204826
https://support.apple.com/kb/HT204658

Our pitiful attempt at security advisories; it's actually a good
advisory, the problem is it's the only one we've ever released: http://
webkitgtk.org/security/WSA-2015-0001.html

Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Michael Catanzaro]

On Thu, 2015-11-05 at 17:35 +0100, Kevin Kofler wrote:
> At least one image that is still consistent with its goals in its 
> application choice. The KDE image is now polluted by Firefox, which
> sticks 
> out like a sore thumb. :-(

I miss QtWebKit. :(

For those not familiar with the history, QtWebKit was deleted from the
upstream WebKit project about three years ago after the maintainers
said they no longer had the resources to continue maintaining it
upstream. It now lives on KDE.org but it's based on an ancient WebKit
revision. I don't know what the security story is there, but I imagine
not good, and I guess that's why you switched to Firefox?

Now bundling is allowed, you can bring in QtWebEngine, and try porting
Rekonq to use that. It's sad to be forced to switch to Chromium
bundleland, but Chromium works well and comes with a top-class sandbox,
so Rekonq would immediately become about 3252389724x more secure than
Firefox or Epiphany. Unless you're willing to use QtWebEngine, I see no
future for Qt-based web browsers. :/

Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Michael Catanzaro]

On Thu, 2015-11-05 at 09:37 -0700, Kevin Fenzi wrote:
> So, in no particular order: 
> 
> * I don't really think it's 'irresponsible' to ship midori in it's
>   current state. It's not ideal, but if you know of specific critical
>   issues not fixed, please let me know. 

There are two ways to look up WebKit security bugs:

* You can just go through the WebKit commit history and look for bugs
that you don't have permission to see. This way you can see what
releases the bug was fixed in, and you can see the changes and the
commit log description, but you cannot see the bug report nor what the
CVEs were. This is what we've been doing recently when we provide a
count of the number of security bugs fixed in a release.

In this way, I can tell you that we've backported the following
security fixes to the 2.10 branch in the past three weeks. I'm not
going further back than three weeks, since it would take too long:

https://trac.webkit.org/changeset/190820
https://trac.webkit.org/changeset/190570
https://trac.webkit.org/changeset/190339

There's never enough data in the commit message to make it easy to
exploit the crash, for obvious reasons, but it's enough to be good
starting points for bad guys. Anyway, if you assume one security issue
a week, you can say you've missed roughly 40-50 security updates so far
this year. Most of these let attackers control your computer.

* You can look at Safari security advisories and read the CVEs listed
under WebKit headings. Apple never releases any details on these bugs
except when Google discovers the bug; it's almost always "Visiting a
maliciously crafted website may lead to an unexpected application
termination or arbitrary code execution." You don't know what
WebKitGTK+ release a CVE was fixed in, nor whether the bug is a Mac-
specific issue or a cross-platform issue, nor can you see the commit
the CVE was fixed in. (We were able to say what CVEs were fixed in a
WebKitGTK+ release for the first time with 2.4.8... and that was also
the last time, since Apple stopped providing us with that info.)

Just the most recent advisories indicate:

September: 34 bugs with impact "Visiting a maliciously crafted website
may lead to an unexpected application termination or arbitrary code
execution" https://support.apple.com/en-us/HT205377

October: 9 bugs with impact "Visiting a maliciously crafted website may
lead to arbitrary code execution" https://support.apple.com/kb/HT205377

You can imagine that there are hundreds of such issues fixed since
January. I'm concerned that the number of CVEs reported here is much
greater than the number of security bugs found by going through the
changelog, and can't explain the difference.

> * Midori upstream is working on moving to webkit2 (for quite a while
>   now). They have the base browser pretty much done, but they still
> are
>   working on porting some of the plugins. They keep hoping to switch
>   defaults soon, but they are a small project and have as much time
> as
>   they have. Any assistance with porting I'm sure would be welcome. 

Unfortunately there are too many apps that need assistance with
porting. :( We have to focus on the GNOME stuff first, which is still
not done. Midori's switch to WK2 has been taking very long, and it will
be great if they manage to finish soon.

Note that all of my complaints about Midori being insecure apply
equally to Evolution and Geary (unless you turn off display of HTML
mail) and anything else stuck on 2.4.

Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Michael Catanzaro]

On Thu, 2015-11-05 at 16:21 +0100, Jos Vos wrote:
> I see that the F23 Xfce live image still includes only Midori as the
> internet browser, similar to the F22 image.

Midori still depends on an old version of WebKitGTK+, so it has not had
any security updates in a long time. It's irresponsible to ship it
until this is fixed.

(This is a problem for a lot of software we ship in Workstation as
well, notably Evolution, Empathy, Rhythmbox, and Shotwell, but it's
even worse for a web browser.)

Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct