WebKit(s) SIG

[Jaroslav Reznik]

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

-- 
Jaroslav Řezník
<jreznik at redhat.com>
Software Engineer - Base Operating Systems Brno

Office:
+420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc.                       
       http://cz.redhat.com/