Re: libxml2 commit 65c7d3b2e6506283eecd19a23dcf0122fbcdac33

[Daniel Veillard <veillard redhat com>]

On Mon, Aug 06, 2012 at 02:27:31PM -0400, Colin Walters wrote:
> 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?

  yep, no problem !

> > 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
> #

  I searched through gogle code search and normal search first and
there wasn't that many hit.

> >   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.

  Actually I had to update this today to really make things work as
expected, rc0 wasn't good enough but the next candidate release
(upstream or rc1 next week) shoud be working as a drop in replacement
(old xsltproc now works fine), so I'm relatively hopeful this will
go smoothy, I just need to make very clear how to udate code when people
recompile.

> > 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.

  http://bugzilla-attachments.gnome.org/attachment.cgi?id=220489
looks fine to me, I will comment along those lines on bugzilla

> >   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.

  I do such trick only once every 10 years, and hope to not have to do
it again before 2022 !!! I agree it's not fun, and I spent quite some
time on this before the push but I didn't want to make noise until I
had something I though was reasonable and would work in the end.

> 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.

  No, I must fix the parser from being vulnerable to various attacks
based on int size being overflown ... this is a default not an option.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel veillard com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/