Re: The security of deflate-compressed streams with uncompressed-length field

There are several points.  The one you are missing is that it is not
possible to write a streaming conversion of compressed PNG data unless
the output PNG chunk size can be calculated before the output chunk
header has to be written.

You seem to be arguing that it isn't a security issue because correct
code can be written without it.  That's the academic approach to
security; the approach that says our bank accounts are secure so long
as we remember (never write down) a different randomly generated
32-character password for each of them.

In practice security breaches on this planet happen when people don't,
or can't, obey the onerous rules required to keep a system secure.
This is why I pushed so hard to get both you and Glenn to attempt to
write the *decompression* code then ended up ROTL when Glenn offered
something that relied on a 0.5MByte stack allocated buffer being large
enough.

You still haven't posted any code.  I guess you could copy mine and
say "it's easy", but I'm the author of that code and I have got it
wrong so many times you would have to be tracking my github libpng
repos to understand.

Saying something *can* be done right, or that it *should* be done
right doesn't solve the basic problem that it *won't* be done right.
Sample code helps, but it needs to be correctly licensed so that it
can be copied.  Glenn has already alluded to that issue by *not* using
the code inside libpng.

>Specifically, libpng should offer a general-purpose inflation routine, such as:

Oh come on!  What on earth does that function do?    Where's the API
documentation?

John Bowler

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot