WebKit(s) SIG

[Vincent Danen]

* [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 / Red Hat Security Response Team