cairo-1.4.14

[ken@…]

Version increment, works for me.

Since the book is on 1.4.10 and versions before 1.4.12 are vulnerable to CVE-2007-5503, I think this ought to go in to 6.3. I'll do it tomorrow, unless anybody objects.

[Randy McMurchy]

Please check the ChangeLog to see if there's been API/ABI changes. I'd hate for newer Cairo to be incompatible with older Gtk+.

If there's a patch to fix the vulnerability, that may be better.

[ken@…]

I can't tell (the ChangeLog isn't in exact date order, and anyway API/ABI changes often slip through accidentally). I didn't know we were supporting old versions. How old ? Is this generally enforced ?

As to a patch, I've found the Mandriva updated srpm for 1.4.10, with an identifiable patch - it's about 48KB. Unfortunately, I don't have an exploit to test it with.

Not sure if I've got anywhere old enough to test this, I'll take a look and see if I can drop a patched 1.4.10 over unpatched 1.4.10 or older anywhere and see if it still works. If you can confirm _how_ old, I'll check to see if I've got any matching x86 systems where I can try to drop in a new cairo to see if anything breaks.

As to putting 1.4.14 (or something newer, perhaps) into 7.0, I can wait.

[ken@…]

Checked what I've still got - building the recent two LFS-6.3 systems, and two LFS systems in Jnauary, hasn't helped. The oldest I've got is from last August, with xorg-7.2, glib-2.12.13, gtk-2.10.13, atk-1.18.0, pango-1.16.1. The good news is that the version of cairo there is 1.4.0 so I can have a play at patching that and seeing if things still run, and even compiling, and also dropping in a virgin 1.4.14.

The bad news is that doesn't really address any issue about older gtk.

[Randy McMurchy]

Ken, I didn't mean that we can't update Cairo. I just wanted to make sure that there weren't changes in the Cairo code to accomodate any changes there may have been in the Gtk+-2.12 series.

Since BLFS is at the Gtk+-2.10 series (and should probably stay there for the 6.3 release) I was just mentioning it as something we needed to check so there wouldn't be breakage.

The vulnerabilities are a concern, though. I can help out with some testing if you need me to.

[ken@…]

OK, I misunderstood. My systems for the 6.3 book are based on LFS-6.3, newer kernel after that, and package versions mostly matching recent BLFS-svn (so, xorg-7.2 gtk-2.10.13, gnome-2.18), except where I think something newer should be used). I was running that with cairo-1.4.14 for two days this week, so I'm fairly sure it doesn't cause any problems.

Still need to finish running the cairo testsuite for 1.4.14, just to check there is no regression to comment on. At the moment I'm on a different box while I do my main backups and try to address some space problems. I'll get back to it soon, I hope.

[dnicholson@…]

I follow the cairo list, and the patchlevel updates should be pretty good to go. They certainly try not to break things until bumping the minor version (if then).

​http://lists.freedesktop.org/archives/cairo/2008-January/012700.html

There is one issue with this release. In cairo, they check the version of the X server and workaround bugs in the Xrender feature EXTEND_REPEAT. The version check had been broken when Xorg moved the version number backwards (to 1.x, where it had been 4.x in Xfree86), so the workaround was always enabled.

With cairo-1.4.14, the version check has been fixed to identify the X server correctly and the workaround will be disable on newer Xorg. However, it looks like newer Xorg still needs the workaround depending on what driver is in use. This hit Mozilla, and they added a patch to force the workaround to always be used:

​https://bugzilla.mozilla.org/show_bug.cgi?id=413583 ​https://bugzilla.mozilla.org/attachment.cgi?id=299854 ​http://lists.freedesktop.org/archives/cairo/2008-January/012845.html

Maybe we should think about that. Otherwise, the update should be fine.

[ken@…]

Replying to dnicholson@linuxfromscratch.org:

​http://lists.freedesktop.org/archives/cairo/2008-January/012700.html

There is one issue with this release. In cairo, they check the version of the X server and workaround bugs in the Xrender feature EXTEND_REPEAT. The version check had been broken when Xorg moved the version number backwards (to 1.x, where it had been 4.x in Xfree86), so the workaround was always enabled.

With cairo-1.4.14, the version check has been fixed to identify the X server correctly and the workaround will be disable on newer Xorg. However, it looks like newer Xorg still needs the workaround depending on what driver is in use. This hit Mozilla, and they added a patch to force the workaround to always be used:

​https://bugzilla.mozilla.org/show_bug.cgi?id=413583 ​https://bugzilla.mozilla.org/attachment.cgi?id=299854 ​http://lists.freedesktop.org/archives/cairo/2008-January/012845.html

Maybe we should think about that. Otherwise, the update should be fine.

Thanks for that info, Dan. Really useful, just not what I wanted to hear.

bugzilla.mozilla seems to be a bit busy at the moment! OK, got there. I don't see this on the ppc I'm sitting at because I got fed up with the 6.7 ati drivers on it (195 no useable screens, 196 ok, 197 locked the box with a blank display) and went back to 6.6. I remember the 6.7s all worked on my x86, I'd better try 6.7.197 there.

If I read the discussion correctly, the cairo devs think it's a different bug, so they're unwilling to apply the workaround (regarded as slow) until the exact problem is identified.

Strangely, their releases are not only "even", they-re doubly-even so 1.4.13 didn't exist. I've diffed from 1.4.12, the commit was the only thing supposedly touching cairo-xlib-surface.c, and I can see the relevant change in the first couple of lines, the rest of it looks to be unrelated (the commit was a cherry-pick from the HEAD (1.5) branch. If I can see the problem, I'll try a ominimal patch.

If I can't see the problem on the x86, I'll try 6.7.196 (as in one of the me-too additions to the bug - others were sis and one of the intel drivers) on the ppc.

Alternatively, it might be that the patch doesn't fix it - that would be problematic - one of those links recommends everyone using 1.4.12 should upgrade.

[dnicholson@…]

You know that xf86-video-ati-6.8.0 is out right? I'm pretty sure they solved most of the issues people were seeing in the release candidates.

[ken@…]

Replying to dnicholson@linuxfromscratch.org:

You know that xf86-video-ati-6.8.0 is out right? I'm pretty sure they solved most of the issues people were seeing in the release candidates.

Yes, I saw a reference to it this week or last, and I downloaded a copy a few minutes ago. But, the problem isn't only for people using the ati driver. I might test it after proving I can create the problem.

[ken@…]

In fact, I can't build 6.7.196 on my (xorg-7.2) system, it requires xorg-server >= 1.3.0. That makes me think it's a problem for people who have updated to newer versions.

Back to the slower x86, let's see if 6.7 works there...

[ken@…]

Fine here. The background-image at you-tube in the url for the mozlla bug is *nothing* like what's in the screenshot of the broken version, so you-tube must have updated it, and the testcase png renders ok (with firefox-2.0.0.11, which was released before the bug was opened).

What seems to be common for the people who reported this was xorg-server-1.3.0.0

I only have the 1.2.0 and 1.4.0.90 versions of xorg-server. How about I put 1.4.14 in, and wait to see if anyone complains ? I could head the attachment up and commit it to -patches (e.g. something like "reverts fix for a broken version test (xorg started at 1 again) which erroneously applied a slow workaround, might be useful for some video drivers with xorg-server-1.3" ? What I can't do, obviously, is determine if it helps, so I don't think the patch should go into the book.

[ken@…]

Updated in r7225, patch committed with a slightly fuller description.