Re: libxml2 commit 65c7d3b2e6506283eecd19a23dcf0122fbcdac33

[Colin Walters <walters verbum org>]

On Mon, 2012-08-06 at 15:05 +0800, Daniel Veillard wrote:

>   So I looked at this more closely. It happens that evolution-data-server
> was using raw xmlOutputBuffer to serialize XML, and then accessing
> directly the fields inside one of the buffer of xmlOutputBuffer. 

Just dropped a patch here:
https://bugzilla.gnome.org/show_bug.cgi?id=681321
Does it look right to you?

> The API
> allowed it by exposing everything from the header to public space,
> mistake done circa 98-99 IIRC and a bit late to fix ... The problem are
> that those buffers were using int instead of size_t for various size
> leading to a variety of troubles including security ones. How to fix
> that while keeping everything pblic API and ABI compatible ? 

I completely understand the difficulty; however this should be weighed
against the fact that libxml2 is a really old library with quite a
number of users.  My build system only builds basically up to
gnome-shell.  You (or someone) should look at a distribution like
Debian/Fedora/whatever to evaluate the impact on more...stuff.

# cat /etc/fedora-release 
Fedora release 17 (Beefy Miracle)
# repoquery --disablerepo=updates --whatrequires 'libxml2.so.2'  | wc -l
283
#

>   The new buffer structure will be ABI compatible with the old ones,
> i.e. the old code as compiled wil be able to work with the new one, as
> the fields with the same values are in the same place in the new
> structures. 

Eeek.  Yes, I see what you've done with the UPDATE_COMPAT macro.  It
should work, I guess.

> leading to something along those lines:
> --- calendar/backends/caldav/e-cal-backend-caldav.c.orig	2012-08-06 12:39:16.368456121 +0800
> +++ calendar/backends/caldav/e-cal-backend-caldav.c	2012-08-06 12:41:20.602442480 +0800

Ah, didn't see you'd made a patch before I started on one.  Yours looks
better, let me fix mine up to look like it.

>   As I said I don't plan to make an official release with the changes
> before September, so there is a bit of time to get this all cleaned up.

Ok.  But as GNOME is a consumer of libxml2, and I want to keep GNOME
building, please in the future send a "heads-up" notification mail for
changes like this.

You might also consider requiring consuming libraries to #define
LIBXML2_NEW_BUFFER_API to get the new one, and keep defaulting to the
old one.