On Tue, Aug 07, 2012 at 09:45:34PM -0400, Ray Strode wrote:
> Hi,
>
> On Mon, Aug 6, 2012 at 3:05 AM, Daniel Veillard <veill...@redhat.com> wrote:
> > 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 ?
> One idea (if you're sure consumers are just reading the public
> structure and not allocating/writing to it):
>
> struct xmlExtendedBuffer {
> xmlBuffer compatBuffer;
> size_t realSize;
> }
that's basically what I did in xmlBuf . But I broke the ABI more
frankly by making the xmlBuf private, as I prefer to have the code
fixed when people recompile. Those buffers were not supposed to be
accessed that way, but people did, they didn't get the supposedly
uneeded accessors, those are available now, it's better to clean things
up for good an not rely on the old buffer for input and output on
newly compiled apps (old buffers are still available for generic
purposes though).
> Then when allocating e.g., an output buffer:
>
> outputBuffer->buffer = &extendedBuffer->compatBuffer;
>
> and any time you need to get at the extended buffer do:
>
> extendedBuffer = (xmExtendedBufferPtr) outputBuffer->buffer;
>
> Any time you need to adjust the size of the buffer, adjust
> extendedBuffer->realSize, and then do
> extendedBuffer->compatBuffer.size = (int) extendedBuffer->realSize;
>
> Though, sizeof(size_t) == sizeof(int) on 32-bit arches so i'm a little
> unsure how swapping one for the other could fix overflow problems.
well on 32 bit arches realloc() fails first if done properly :)
I'm running my F17 with the patched libxml2 so far so good with
git head
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
