Bug#737843: manipulate unzip behavior

[Daniel Kahn Gillmor]

On Mon 2015-11-16 02:52:49 -0500, Emmanuel Bourg wrote:
> Another point worth considering, uscan doesn't apply a filter equivalent
> to 'unzip -a' to .tar.gz archives, so for consistency I'd argue that it
> shouldn't do it for zip archives either and unpack the files as is.

fwiw, my initial concern was gutmann's cryptlib.

But alas, i don't think cryptlib is suitable for debian, for a number of
reasons:

  https://www.debian-administration.org/users/dkg/weblog/74

So please don't make this consideration for debian based on any
particular cryptlib idiosyncracies.

however...

> I realize I didn't explain in my initial report why the transformation
> of the files was an issue for javamail. The file affected [1] is
> involved in a test case that is sensitive to the line endings [2]. Most
> of the lines in folddata end with \n, but a few of them are terminated
> by \r\n to cover some corner cases with different line endings. The
> transformation performed by uscan alters folddata and causes the test to
> fail.

By definition, it sounds to me like javamail is providing bad data if
they distribute this as a pkzip file.  Given that the pkzip format has
the semantics for how line endings should be treated, if it really needs
these line endings to be byte-for-byte identical for the tests to
succeed, it should mark the file in question as a binary file, not a
text file.

     --dkg