[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 188.8.131.52).
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