9:21 a.m.
Hi,
I see that the F23 Xfce live image still includes only Midori as the
internet browser, similar to the F22 image.
With F22 I had the unpleasant surprise that, using the Xfce live image,
Midori was for some reason not able to sign in (web form) on a store's
public wifi network, because of some issue when redirecting to a HTTPS
page with an own-signed certificate or so (this was in the Media Markt,
if you want to know...).
As I wanted to test a laptop for Linux compatibility booting from USB
and at that point I didn't have an alternative network connection,
this was a real showstopper. As I saw the wifi networks listed, I took
the risk to consider the laptop (i.e. the wifi adapter) working, and
this happened to be ok, but I would suggest to consider including
Firefox as (another) browser, just in case the live image has to be
used for some special (rescue/testing) purposes and you need a more
versatile browser than Midori.
PS
I didn't add a bug report as I was not able to reproduce the problem
outside the store and I couldn't describe the problem in enough details
anymore.
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
9:53 a.m.
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
10:22 a.m.
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.
10:23 a.m.
----- 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.
10:37 a.m.
On Thu, 05 Nov 2015 10:22:23 -0600
Yaakov Selkowitz <yselkowi(a)redhat.com> 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
12:23 p.m.
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
12:38 p.m.
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
11:49 a.m.
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
10:35 a.m.
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
10:37 a.m.
On Thu, Nov 5, 2015 at 11:35 AM, Kevin Kofler <kevin.kofler(a)chello.at>
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
12:28 p.m.
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
1:07 p.m.
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
1:40 p.m.
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
3:08 p.m.
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
3:20 p.m.
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
2:53 p.m.
On Thu, Nov 05, 2015 at 16:21:07 +0100,
Jos Vos <jos(a)xos.nl> wrote:
With F22 I had the unpleasant surprise that, using the Xfce live image,
Midori was for some reason not able to sign in (web form) on a store's
public wifi network, because of some issue when redirecting to a HTTPS
page with an own-signed certificate or so (this was in the Media Markt,
if you want to know...).
What I have noticed is the Midori adds a question mark to the URL if it
doesn't have one when there is an expired certificate which breaks some
things. It also doesn't seem to let you say the except expired certs
for the session, which makes things like reading the bufferbloat archives
really annoying.
3102
days inactive
3103
days old
15 comments
8 participants
participants (8)
-
Bastien Nocera -
Bruno Wolff III -
Dan Book -
Jos Vos -
Kevin Fenzi -
Kevin Kofler -
Michael Catanzaro -
Yaakov Selkowitz