Hi all (and if not all, feel free to add them to CC). I'd like to establish WebKit SIG (or some sort of group of people interested in WebKit in Fedora - no need for any official one) as it's quite an overhead to maintain such a big beast here. We have QtWebKit, WebKitGtk, Chromium, KHTML... All very similar but based on different toolkit, concept etc. and it's mess currently (with responsibilities etc).
What's the reason? - all WebKit-like implementations are very similar with only a little differences (toolkit...) - there are quite a lot of CVEs - it's time consuming to go over all CVEs (thanks for great job goes to Vincent Danen and other brave men from security response team) and most of patches could be shared - a lot of bugs affects all implementations - again patches sharing - sometimes the primary maintainer of one of WebKits is out of time - that means other team member could help - and probably many other reason like we are on the same WebKit ship (and if it's going to sink...)
What can I bring to the team? I'm a current primary QtWebKit maintainer (with help of rest KDE SIG people), upstream's WebKit security team member. I don't care about used toolkit - I offer help with Gtk and other ones too - what I care is user experience.
If you're interested in - please reply, I'd like to start Wiki page and we can talked about more details etc.
Thanks Jaroslav
On Fri, 2010-08-06 at 16:45 +0200, Jaroslav Reznik wrote:
Hi all (and if not all, feel free to add them to CC). I'd like to establish WebKit SIG (or some sort of group of people interested in WebKit in Fedora - no need for any official one) as it's quite an overhead to maintain such a big beast here. We have QtWebKit, WebKitGtk, Chromium, KHTML... All very similar but based on different toolkit, concept etc. and it's mess currently (with responsibilities etc).
I'm not sure about KHTML. Yes, WebKit is originally a fork of KHTML, but AFAIK the current code bases differ too much...
What's the reason?
- all WebKit-like implementations
are very similar with only a little differences (toolkit...)
Not sure how "little" the differences are, but yeah, there's a big common ground for all the ports and it would be ideal if we could separate it out.
- there are quite
a lot of CVEs - it's time consuming to go over all CVEs (thanks for great job goes to Vincent Danen and other brave men from security response team) and most of patches could be shared
It would much help if we knew which CVEs were already fixed by upstream and in which SVN snapshot and what SVN snapshot the ports are building on. It gets a bit tougher with stable branches which usually have backport fixes and such...
- a lot of bugs affects all implementations -
again patches sharing
Same as above.
- sometimes the primary maintainer of one of WebKits is
out of time - that means other team member could help
- and probably many
other reason like we are on the same WebKit ship (and if it's going to sink...)
+1
If you're interested in - please reply, I'd like to start Wiki page and we can talked about more details etc.
Yeah a wiki page would be helpful. Plus as I already outlined in another mail, this effort would be futile without full support from upstream -- I don't think there are *any* releases of WebKit core components at all so the ports differ a lot on which SVN snapshot they build upon, and to establish this common ground, cooperation from upstream is needed. For starters we should probably identify what our current position is -- i.e. what are the webkit ports used in fedora, which SVN snapshot they use, what are the core components of webkit, the differences in build systems, ... And outlining the idea of splitting/merging.
Anyway, I would be interested in helping, although I doubt I could help much, given my low to none knowledge of webkit internals and little time, but as a full time user of webkitgtk based apps, I'm highly interested in having them work in reasonable way.
Regards, Martin
On Friday, August 06, 2010 05:15:12 pm you wrote:
On Fri, 2010-08-06 at 16:45
+0200, Jaroslav Reznik wrote:
Hi all (and if not all, feel free to add
them to CC).
I'd like to establish WebKit SIG (or some sort of group
of people interested in WebKit in
Fedora - no need for any official one)
as it's quite an overhead to
maintain such a big beast here. We have
QtWebKit, WebKitGtk, Chromium,
KHTML... All very similar but based on
different toolkit, concept etc.
and it's mess currently (with
responsibilities etc).
I'm not sure about KHTML. Yes, WebKit is
originally a fork of KHTML, but
AFAIK the current code bases differ too
much...
It's more complicated - some parts are completely different, some backported from WebKit, some code is the same line-by-line, some rewritten. But with every WebKit's CVE we are trying to reproduce it in KHTML and if we can't reproduce it, we try to do a code review together with security response team.
What's the reason?
- all WebKit-like implementations
are
very similar with only a little differences (toolkit...)
Not sure how
"little" the differences are, but yeah, there's a big
common ground for all
the ports and it would be ideal if we could
separate it out.
Some issues are really toolkit-specific but from my observations - most of bugs applied on all WebKits.
- there are quite
a lot of CVEs - it's time consuming to
go over all CVEs (thanks for great
job goes to Vincent Danen and other
brave men from security response
team) and most of patches could be
shared
It would much help if we knew which CVEs were already fixed by
upstream
and in which SVN snapshot and what SVN snapshot the ports are
building
on. It gets a bit tougher with stable branches which usually have
backport fixes and such...
CVEs are usually fixed upstream but still you have to go through all bugs and check it in all WebKits implementations (snapshot revisions could help of course). WebKits shipped by Fedora usually differs - different snapshots (but not big changes).
- a lot of bugs affects all
implementations -
again patches sharing
Same as above.
sometimes the primary maintainer of one of WebKits is
out of time - that
means other team member could help
- and probably many
other reason
like we are on the same WebKit ship (and if it's going to
sink...)
+1
If you're interested in - please reply, I'd like to start Wiki
page and we can talked about more details
etc.
Yeah a wiki page would
be helpful. Plus as I already outlined in another
mail, this effort would be
futile without full support from upstream --
I don't think there are *any*
releases of WebKit core components at all
so the ports differ a lot on which
SVN snapshot they build upon, and to
establish this common ground,
cooperation from upstream is needed.
There's quite a big mess on WebKit's security list, Vincent suggested few changes, let's see. Another question is how to make releases in sync - to have same snapshots in Fedora.
For
starters we should probably identify what our current position is --
i.e.
what are the webkit ports used in fedora, which SVN snapshot they
use, what
are the core components of webkit, the differences in build
systems, ... And
outlining the idea of splitting/merging.
Any merging is really upstream (upstreams) problem but yes - we need to clean up WebKits situations - what we really have, who is consumer of which one etc.
Anyway, I would be
interested in helping, although I doubt I could help
much, given my low to
none knowledge of webkit internals and little
time, but as a full time user
of webkitgtk based apps, I'm highly
interested in having them work in
reasonable way.
Great (and yes, latest WebKits crashes - icedtea plugin is cross WebKits one)!
Jaroslav
Regards, Martin
* [2010-08-06 17:28:46 +0200] Jaroslav Reznik wrote:
On Friday, August 06, 2010 05:15:12 pm you wrote:
On Fri, 2010-08-06 at 16:45
+0200, Jaroslav Reznik wrote:
Hi all (and if not all, feel free to add
them to CC).
I'd like to establish WebKit SIG (or some sort of group
of people interested in WebKit in
Fedora - no need for any official one)
as it's quite an overhead to
maintain such a big beast here. We have
QtWebKit, WebKitGtk, Chromium,
KHTML... All very similar but based on
different toolkit, concept etc.
and it's mess currently (with
responsibilities etc).
I'm not sure about KHTML. Yes, WebKit is
originally a fork of KHTML, but
AFAIK the current code bases differ too
much...
It's more complicated - some parts are completely different, some backported from WebKit, some code is the same line-by-line, some rewritten. But with every WebKit's CVE we are trying to reproduce it in KHTML and if we can't reproduce it, we try to do a code review together with security response team.
We pretty much have to. Just because a proof of concept fails to work on KHMTL isn't grounds for saying it isn't affected -- it is possible that it can affect KHTML with slight tweaks. Unfortunately, this means we need to look at the code (currently we concentrate on RHEL alone, but with RHEL6, we were looking at webkitgtk and qtwebkit, plus KHTML in KDE4 vs KHTML in KDE3). Painful stuff.
What's the reason?
- all WebKit-like implementations
are
very similar with only a little differences (toolkit...)
Not sure how
"little" the differences are, but yeah, there's a big
common ground for all
the ports and it would be ideal if we could
separate it out.
Some issues are really toolkit-specific but from my observations - most of bugs applied on all WebKits.
They do and they don't. It depends on the svn revision and what has been cherry-picked to a particular tree. It really is an insane mess. We had a lot of things that affected webkitgtk and not qtwebkit (and vice versa) depending on the version and when/if a new snapshot was taken.
- there are quite
a lot of CVEs - it's time consuming to
go over all CVEs (thanks for great
job goes to Vincent Danen and other
brave men from security response
team) and most of patches could be
shared
It would much help if we knew which CVEs were already fixed by
upstream
and in which SVN snapshot and what SVN snapshot the ports are
building
on. It gets a bit tougher with stable branches which usually have
backport fixes and such...
CVEs are usually fixed upstream but still you have to go through all bugs and check it in all WebKits implementations (snapshot revisions could help of course). WebKits shipped by Fedora usually differs - different snapshots (but not big changes).
Sure, they're fixed upstream, and if we make a policy of grabbing snapshots then we're probably fine. This wouldn't be acceptable for RHEL, of course, and I doubt it would be acceptable for Fedora (excluding rawhide).
Having said that, when you have access to the upstream bugs, they are quite clear on what revision fixes a flaw, so patches are easy enough to come by.
- a lot of bugs affects all
implementations -
again patches sharing
Same as above.
sometimes the primary maintainer of one of WebKits is
out of time - that
means other team member could help
- and probably many
other reason
like we are on the same WebKit ship (and if it's going to
sink...)
+1
If you're interested in - please reply, I'd like to start Wiki
page and we can talked about more details
etc.
Yeah a wiki page would
be helpful. Plus as I already outlined in another
mail, this effort would be
futile without full support from upstream --
I don't think there are *any*
releases of WebKit core components at all
so the ports differ a lot on which
SVN snapshot they build upon, and to
establish this common ground,
cooperation from upstream is needed.
There's quite a big mess on WebKit's security list, Vincent suggested few changes, let's see. Another question is how to make releases in sync - to have same snapshots in Fedora.
Unfortunately, no one from upstream seems to even want to discuss those suggested changes. =( And I don't know if they will. Right now we often get three CVE names for a particular flaw because upstream's bugs are usually private, and Apple and Google both have different release schedules (and they are the two largest players here). So we end up with a CVE for Safari, one for Chrome, and another for WebKit. This makes tracking and managing this stuff an insanely time-consuming effort and would be impossible without being able to reference upstream bugs (which are usually private).
For
starters we should probably identify what our current position is --
i.e.
what are the webkit ports used in fedora, which SVN snapshot they
use, what
are the core components of webkit, the differences in build
systems, ... And
outlining the idea of splitting/merging.
Any merging is really upstream (upstreams) problem but yes - we need to clean up WebKits situations - what we really have, who is consumer of which one etc.
This will be very hard to do. Honestly, until upstream decides to realize that they are making a lot more work for everyone and these big companies decide to play nice and share a backend _fully_ with their own particular frontend, this is going to be a lot of effort.
Unfortunately, with the popularity of webkit, I don't see how we can _not_ do this.
So count me in, and please forgive me in advance if I seem grumpy whenever we talk about webkit. =)
Vincent Danen wrote:
Unfortunately, no one from upstream seems to even want to discuss those suggested changes. =( And I don't know if they will. Right now we often get three CVE names for a particular flaw because upstream's bugs are usually private, and Apple and Google both have different release schedules (and they are the two largest players here). So we end up with a CVE for Safari, one for Chrome, and another for WebKit. This makes tracking and managing this stuff an insanely time-consuming effort and would be impossible without being able to reference upstream bugs (which are usually private).
To me, this is a prime example of why it sucks to have corporations control Free Software projects. They only care about their own schedules, they branch releases at arbitrary times when it suits them (heck, even Red Hat has done that at times, *cough* GCC 2.96 *cough*, but for WebKit, it is systematic), as a result, they care much more about their branch than upstream and they refuse to support anything other than their private branch, which is of course different from any other company's private branch, and they even release security fixes on their own schedules, making coordinated disclosure a lost cause. :-(
What's particularly ridiculous is that, even though both webkitgtk and QtWebKit are now driven by Nokia (since the Trolltech acquisition), they have completely separate release schedules. If only those two projects would share a common codebase and schedule (which sounds more achievable now that QtWebKit is being split out of Qt), that'd already help us a lot (it'd only leave Chromium as being weird). I guess it might make sense to bug some people at Nokia to see if something can be achieved there.
Kevin Kofler (who is particularly grumpy because KDE is relying more and more on a fork of KHTML which was made to eliminate KDE dependencies (!), then ported back to Qt in an ugly way (fake widgets (*) etc.), then ported back to KDE in an even uglier way (WebKit's network access abstraction uses Qt's network access abstraction which then finally uses KDE's KIO network access abstraction, yay), and several parts don't even use the KDE integration, only the Qt one (yuck!))
(*) What I call a fake widget is a widget drawn using QStyle directly, with all the logic implemented inside the application or some high-level library (QtWebKit here) instead of using Qt's widgets.
The QtWebKit team announced recently that they plan to do separate QtWebKit releases and be no longer tied to Qt's release schedule.
IMO it would be cool if QtWebKit and WebKit-GTK could so far work together that both teams work off the same branched code base.
On Friday, August 06, 2010 04:45:39 pm Jaroslav Reznik wrote:
Just an update: we hava our own WebKit SIG mailing list [1]. Feel free to subscribe.
[1] https://admin.fedoraproject.org/mailman/listinfo/webkit
Thanks Jaroslav
-
Huzaifa Sidhpurwala -
Jaroslav Reznik -
Kevin Kofler -
Markus Slopianka -
Martin Sourada -
Vincent Danen