[xml/sgml-pkgs] Bug#565683: Bug#565683: Peers inside zlib internal code

[Mike Hommey]

On Sun, Jan 17, 2010 at 10:29:51PM +0000, Mark Brown wrote:
> Package: libxml2
> Version: 2.7.6.dfsg-1
> Severity: important
> 
> The new version of zlib, 1.2.3.5, contains a new implementation of gzio
> (the gzopen() and related API calls) which are used by libxml2.  Sadly
> it looks like these break libxml2.  It contains (in xmlIO.c) the
> following code:
> 
>             if (((z_stream *)context)->avail_in > 4) {
>                 char *cptr, buff4[4];
>                 cptr = (char *) ((z_stream *)context)->next_in;
>                 if (gzread(context, buff4, 4) == 4) {
>                     if (strncmp(buff4, cptr, 4) == 0)
>                         ret->compressed = 0;
>                     else
>                         ret->compressed = 1;
>                     gzrewind(context);
>                 }
> 
> where context boils down to a gzFile returned by zlib.  The code here is
> assuming that the first memeber of this structure is a zlib stream which
> is true for current zlib versions but is no longer true for this new
> implementation.  Since gzFile is a void * in the public API (the
> structure is defined file local in the zlib source) this is a case of
> libxml peering into the implementaiton of zlib in a way it isn't
> supposed to.
> 
> The code also appears to be assuming that gzopen() does an initial read
> from the file (this is in the open path and I can't find any following 
> code which does the same check) which is also no longer the case but
> that is less harmful since the avail_in check will just fail.
> 
> I'm discussing this with zlib upstream at the minute but I expect that
> whatever happens libxml is going to need to be fixed to stop peering
> inside the zlib internals here.  We may be able to use symbol
> versioning to maintain existing binary compatibility but that'll still
> cause breakage as soon as libxml is rebuilt, and due to the casting from
> void there's nothing I can see zlib can do to catch this itself.
> 
> I'll upload my current zlib 1.2.3.5 package to experimental later for
> you to take a look at.

Would you mind poking the xml at gnome.org list, where you could explain
the issue much better than I would to upstream ? Or maybe zlib upstream
should do that...

Mike