* [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
> I'm not sure about KHTML. Yes, WebKit is
originally a fork of KHTML, but
> AFAIK the current code bases differ too
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
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.
are really toolkit-specific but from my observations - most of bugs applied on
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
> > - 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
> It would much help if we knew which CVEs were already fixed by
> and in which SVN snapshot and what SVN snapshot the ports are
> 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
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
> > - a lot of bugs affects all
> > 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...)
> > 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).
starters we should probably identify what our current position is --
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