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/ [email protected] | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
