[Png-mng-security] vulnerability in png_decompress_chunk()
ctruta at gmail.com
Thu Feb 4 00:58:10 UTC 2010
On Fri, Jan 29, 2010 at 5:52 PM, John Bowler <jbowler at frontiernet.net> wrote:
> From: Glenn Randers-Pehrson [mailto:glennrp at gmail.com]
>> I guess then, 1.4.1 should become 1.5.0 (and 1.5.0alpha01 in the GIT
>> repository should become 1.6.0alpha01).
> Definitely *NOT*.
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...
> This mess arises because the two C structs 'png_struct' and 'png_info' are declared in the public header file, png.h. *Use* of these definitions beyond the jmp_buf member at the head has been deprecated for aeons.
The formal act of deprecation is not so relevant. It's the
availability of reasonable alternatives that matter. And in this case,
libpng is still lacking the alternatives.
A few months ago I posted a message in which I was explaining that
members of a structure should be hidden only when there is a complete
API around it. In libpng, in particular, you can get the data, you can
set the data, but you cannot clear the data. Most libpng developers
might not care, but I need to clear the data in OptiPNG, and I must
use direct access for that reason.
> For certain release 1.5 (or 1.6, whatever) should no longer include either png_struct or png_info in *any* of the installed header files.
So in my above-mentioned email I proposed the introduction of
png_clear_XXX() functions in addition to png_get_XXX() and
png_set_XXX(), to which Glenn replied something like "maybe later".
That is good enough for me; but please, do not remove the direct
access before the API is complete. Moreover, if png_clean_XXX()
functions are added in libpng version x.y.z, do not remove the direct
access until (at the very least) libpng version x.(y+1).0.
>> People are already angry about having to "clean up after the libpng
>> developers" for suddenly removing png_check_sig() [with only about
>> 13 years' notice!]
> Software writers always complain if they have to maintain the software they've written.
I agree with your point in general, and PNG_DEPRECATED will probably
help in the future.
But this is not the issue here. Direct access is still needed. In
addition, under-the-radar ABI break can be way worse than just
removing a function. When the API breaks, compiler errors occur, and
the programmer's intervention (i.e. the fix) is promptly required. But
when the ABI breaks, bad things usually happen, without anyone
knowing. Please try to avoid ABI breakage, as a general rule.
One thing that is very nice in zlib, for instance, is that an obvious
run-time error occurs across changes in the size of zlib's structures.
More information about the png-mng-security-archive