WebKit: Heads-up! (ABI update, rebuilds required for WebKit GTK+ clients)

Peter Gordon peter at thecodergeek.com
Sat Apr 12 23:55:20 UTC 2008


Hi, all.

In order to fix a couple of security issues [1,2], I've committed a
version bump to WebKit to a recent SVN snapshot

Unfortunately, the previous qmake-based build scripts are no longer
supported for the GTK+ port (and create lots of nasty compilation errors
as noted in upstream's bugzilla [3]). To this end, I have switched the
build system for the GTK+ port to using the autotools scripts. 

Unfortunately, this changes the library from libWebKitGtk.so to
libwebkit-1.0.so (and related), and puts the headers in a new
subdirectory in the include directory (since there are now headers for
WebKit itself as well as its JavaScript interpreter).

This means that rebuilds are required for anything which depends on
WebKit-gtk. Using repoquery, this list is thankfully rather short.

* midori (which I maintain and have bumped)
* kazehakase (maintained by Mamoru Tasaka; bug 442222 [4] filed)

As can be seen from the Midori update, a simple EVR bump plus rebuild is
all that should be required. There are two major changes in this:
(1) The WebKitGtk library and pkgconfig files have been renamed to
webkit-1.0 and so on. The include directory has also been renamed
similarly. 
(2) The webkit.h header has moved from <webkit.h> to <webkit/webkit.h>

Some simple sed invocations, if needed, should suffice to fix these two
renames for packages. The API is compatible with the previous EVR
already in Fedora.

After WebKit and Midori are built, I will email rel-eng to tag these
appropriately for f9-final once they are built through Koji.

I understand that breaking ABI this late in the release cycle is rarely
- if ever - a good idea. However, I believe this to be one of those rare
times, as vulnerable web browser code is often a critical target for
malware (and one of these is a potential entry way for arbitrary code
execution); and fixing these vulnerabilities quickly is far more
important than maintaining ABI for other packages, especially when those
other packages can be quickly and readily fixed for the update.

Alas, I had spent several nights perusing through upstream's Trac and
could not pin-point any specific commits which fixed the issues in
question (which, if backported, may have maintained ABI). Therefore I
felt it appropriate to bump the package to a newer snapshot in total.

Thanks. =)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=438531
[2] https://bugzilla.redhat.com/show_bug.cgi?id=438531
[3] https://bugs.webkit.org/show_bug.cgi?id=17912
[4] https://bugzilla.redhat.com/show_bug.cgi?id=442222
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080412/5c24eca2/attachment.sig>


More information about the fedora-devel-list mailing list