WebKit(s) SIG

Kevin Kofler kevin.kofler at chello.at
Sun Aug 8 18:55:09 UTC 2010


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.



More information about the kde mailing list