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

On 5 February 2017 at 12:34, John Bowler
<[email protected]> wrote:
> 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.

I'm not "missing" anything. It _is_ possible to do it, and it has been
done, by the means of dynamically-allocated arrays. It only looks
complicated from a C programmer perspective, where such arrays do not
come with the standard library and need a separate implementation. It
is a complete non-issue in any other language, statically-compiled or
dynamically-executed, from C++, to Go/Rust, to Python/Ruby.

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

That would be ok if you would replace an "academic approach" with a
"simple approach". But what I do argue here is that you'd need to
replace a plain "academic approach" with another (albeit different)
"academic approach" _plus_ a "security approach".

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

What do you mean by "still"? I just started the discussion here.

And, by the way, I already did post my Python one-liner "zlib.decode(foo)".

Can it be done properly? Could you do it properly? Could the zTXt or
iCCP implementors do it properly? Could the Python zlib library
implementors do it properly? Could any other library implementors
(including boost::zlib_decompressor in C++) do it properly?

So it can be done.

On the topic of you getting it so wrong, so many times: I have seen
people getting quicksort wrong so many times, but I do not make
generalizations. It is a matter of personal skill, and I would rather
prefer not to continue the discussion on this topic.

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

I thought it's easy to figure out. If you can't, that's fine. If you
ask me nicely for details and clarifications, I may even respond. But
if you ask "what on Earth", as if you had no slightest clue, then I
cannot respond to that.

I actually volunteer to write it for libpng, because it is an
omission. It needs to be in v1.6 and v1.2 and everything in between,
since there are apps still depending on v1.2.

But I plan on doing it at my own pace, on my own personal time, so
(John) please refrain from doing as you did in the past, being
increasingly imperative all the way to using shouty capital "PROVE IT"
letters and exclamation marks. Please do your homework instead. The
simple fact that you claim inability to do something does not mean
that nobody else can, and the recent-past "uncompressed deflation can
be done with 3 function calls or less" debacle is testament to that.

Sincerely,
Cosmin

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