[Png-mng-security] vulnerability in png_decompress_chunk()

glennrp at comcast.net glennrp at comcast.net
Thu Feb 4 12:52:18 UTC 2010

----- Original Message -----
From: "Cosmin Truta" <ctruta at gmail.com>
To: png-mng-security at simple.dallas.tx.us
Sent: Wednesday, February 3, 2010 9:35:09 PM GMT -05:00 US/Canada Eastern
Subject: Re: [Png-mng-security] vulnerability in png_decompress_chunk()

On Wed, Feb 3, 2010 at 9:06 PM, John Bowler <jbowler at frontiernet.net> wrote:
> From: Cosmin Truta
>>John, why do you insist so much on breaking the ABI?
>>Just bump the
>>minor version number, recompile the software that, anyway, needs
>>recompilation, and you're done. Version numbers are free...
> If the ABI changes the major version number must be changed, that's what "major" means in this context; that if it does not change the ABI is unchanged.

     Just to be precise, it is the minor version number that gets
     bumped when the ABI changes.  1.0.x, 1.2.x, 1.4.x are "minor
     versions".  I guess the leading "1." is just a decoration for
     now, but when we make a libpng that looks really different
     from 1.x.x, we'll call it 2.0.0.  I think making the
     png_struct opaque probably falls in that category, although
     we do seem to be sneaking up on that via the PNGDEPSTRUCT

> We're living in a fantasy land.  We assert that additions to *end* of png_struct or png_info aren't ABI changes because we effectively but quietly make it illegal for the user of libpng to declare a png_struct or png_info.  We also deprecate direct access to png_struct or png_info other than the jmpbuf (and, in 1.4, including the jmpbuf).  Despite this some very experienced libpng programmers do directly access the structures because they find the API inadequate: you and either Glenn or Bob (ImageMagick directly accesses 'ping_info', at least in

     I've been maintaining coders/png.c for both ImageMagick and
     GraphicsMagick, but I didn't design it.  It does a lot of
     stuff that libpng could really be doing for it.  Getting rid
     of those deprecated references has been on my low-priority
     "to do" list for maybe six years.  It's a big, error-prone
     job since there are about 250 such references.  And because
     of the GM/IM fork, the whole mess has really got to be fixed

Well, adding things at the end of png_struct/png_info, almost at every
new libpng release,

     For the hundredth time, please don't exaggerate.  We added
     new members five times in the 1.2.x series and once (proposed)
     so far in 1.4.x.

did not break anything for me yet, and I believe,
neither for Glenn/Bob. But I don't deny a scenario in which things
could break, and I would support removing the contents of the png
structures, after the API is complete from the access perspective.

     I still have not received a definitive answer to whether doing that
     requires a minor version bump (and a bump in the shared library name).

> If we need a set of 'clear' functions in 1.5 that's fine by me.  What I dislike is the idea that we don't make progress on this now.

       Is "png_set_invalid()" not sufficient?  That's been in the
       since 1.0.7.  Maybe using it would cause memory leakage but
       that could be fixed without changing the ABI/API.


More information about the png-mng-security-archive mailing list