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.
_______________________________________________
kde mailing list
kde@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/kde
New to KDE4? - get help from http://userbase.kde.org
