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

Cosmin Truta ctruta at gmail.com
Thu Feb 4 02:35:09 UTC 2010

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?
> You mean on *not* breaking the ABI.  I.e. why am I so very much against an architecture where so many API additions end up breaking the ABI (because they need additions to png_struct or png_info and, because these structures are exposed, this changes the *ABI* even though the *API* is completely backwards compatible.)

Aha, ok, then I misread your previous discussion with Glenn (something
that I started doing more frequently, recently, due to lack of time to
read the whole discussion thoroughly, and for which I apologize...)

I only care to have my programs still working reliably after a libpng
upgrade in the system, that's all ;-)

>>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.

The upgrade from 1.2 to 1.4 worked, (almost) only with recompilation,
and so did the upgrade from 1.0 to 1.2. I don't see why not continue
this habit, and leave libpng-2.0.0 for a major overhaul (e.g. no more
separation between png_struct and png_info).

But if you insist on changing the major version number sooner, given
that, perhaps, there will never be such a massive API change, I
wouldn't be awfully opposed to it.

> 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

Well, adding things at the end of png_struct/png_info, almost at every
new libpng release, 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.

> The entire interface needs to be function based - no tweaking values out of memory.

I agree that this is a goal to reach, and I think it's reachable.

> 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.  Better a 1.5.0 that breaks some apps than a 1.5.* that requires a 1.6 the next time we need to add a security related API enhancement.

When Glenn postponed this project, he did so (I think) because he was
busy getting libpng-1.4 out the door. Is there any other major libpng
work pending? If not, this could be the next thing to do. I leave it
up to you to decide on whether to do it for 1.4 or 1.5. Among other
things, that depends on whether the introduction of a new module (e.g.
pngclear.c) can or cannot be done in 1.4.

Best regards,

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