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

Willem, before getting into details, let me start by saying that I
opened this topic deliberately outside of the EXIF discussion, for the
very reason *not* to get into the compressed-vs-uncompressed EXIF
debate. I will neither agree nor disagree with your claims on EXIF
compressibility in my response below.

I opened this topic in response of the claim that *current* standard
compressed chunks have been affected by DoS attacks, and we should not
make new ones like that anymore. I counter that argument, claiming
that the implementation was not engineered properly, and the solution
should be a correct re-engineering of that implementation.

And I offered a prototype and the pathway to the *easy* and *correct*
implementation.

On 5 February 2017 at 22:34, Willem van Schaik <[email protected]> wrote:
> I do hear you (as quoted below) "some people have been able to implement
> correctly", which means to me that many have not been able to do that

It means that some people (e.g. John Bowler) claimed that it was
difficult for them to implement, therefore it should be difficult for
anyone to implement, and I countered that claim. My claim is that is
should be easy.

> so it seems there are some none trivial issues here to implement zTXt or
> zXIf correctly

I am debating the necessity of an uncompressed-length field specifically.

I am claiming that IIABDFI (If It Ain't Broken Don't Fix It), and I am
claiming that zTXt Ain't Broken, so Don't Fix zXIf.

Arguments to the contrary should result in stopping zXIf in the
tracks, going back to the drawing board, deprecating zTXt, and, more
importantly, deprecating iCCP (because its implementation is claimed
to be very difficult and error prone), and adding in something like
"nICP" (New Internet Color Consortium Profile) that is, supposedly,
designed properly.

But I am mentioning that theoretically. My claim is that it is
perfectly fine as it is, and if anything needs fixing, is the approach
to its implementation.

> then why are you so argumentative that we need a compressed version of
> eXIf ?

I can still defend it, until voting starts, but let us do that in the
other thread about eXIf.

> 1) it does give all the dangers of the bad security exploits that you
> and John are both aware of and therefore discussing, but that you think
> could be avoided by someone who knows what he/she is doing ... IMHO if
> that danger is lurking, some hacker in Russia or China will find a way
> around it

I was specifically arguing that adding the uncompressed-length field
is not better than, but it may be worse than not adding it.

iCCP does not give dangers to security exploits any more than PNG
itself. Neither does zXIf.

Have you seen this?
http://www.libpng.org/pub/png/libpng.html
(Scroll down to "Security and Crash Bugs")

By your argument, you should stop using PNG altogether, asap, no?...

> 2) given a realistic multi-MB camera image file that the camera owner
> otherwise would have stored RAW, but is ok with lossless PNG, then
> adding couple of kB because of a non-compressed EXIF chunk doesn't
> matter a dime

You are correct, which is why I will vote YES on uncompressed EXIF if
the compressed-EXIF proposal ends up failing.

> 3) nobody seems to be using zTXt (zero out of twelve-hundred), so why
> would anybody now suddenly use zXIf ... all serious decoder programmers
> would have to embark on it, while nobody will use it

I can continue this discussion in the other thread, regarding EXIF.

> trying to remember, I don't think you've ever really contributed
> anything to the PNG spec ... you've either made proposals that nobody
> liked, or you've obstructed proposals of other people ... can't remember
> anything constructive

I joined the group in 2000, when all of the PNG spec was mostly done,
and the rest were only editorial changes.

I did contribute a considerable amount of implementation efforts, to
libpng and PNG-supporting applications. Please count the occurrences
of my name in the change log. Please include zlib, too, because it is
I who devised and implemented Z_RLE, for the sake of better
compression of PNG images.

Spec-wise, I only contributed to MNG. Over there, I actually did have a chance.

PNG extension-wise, I voted NO for APNG. (Most of the other people did
the same.) I also voted NO on the "Screenshot URL" keyword, and again,
I was not the only one. I voted either YES or ABSTAIN on all the other
previous proposals.

Also PNG extension-wise, I contributed the "Collection" keyword.

Effort-wise, I spent most of it making PNG images better (thus making
PNG itself better), implementing OptiPNG, contributing to pngcrush,
writing articles (on the Internet and in print), and book sections.
There are over a million downloads for my project at SourceForge, with
a considerable amount of downloads per day, and that is not counting
binaries distributed by many Linux distros outside of SourceForge.

And last but not least:

It is I who brought up the EXIF topic in discussion.

> ... can't remember
> anything constructive

Your memory ==> your problem.

Sincerely,
Cosmin

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