Bug#775640: libarchive-zip-perl: FTBFS: Tests failure (unzip/CVE-2014-8139 regression?)

[Niko Tyni]

found 775640 1.30-6
tag 775640 + wheezy
retitle 775640 libarchive-zip-perl: FTBFS: Test failure (unzip/CVE-2014-8139 regression?)
thanks

On Sun, Jan 18, 2015 at 04:34:54PM +0100, gregor herrmann wrote:
> On Sun, 18 Jan 2015 01:41:42 +0100, Lucas Nussbaum wrote:
> 
> > > Test Summary Report
> > > -------------------
> > > t/17_bug_73797.t            (Wstat: 256 Tests: 4 Failed: 1)
> > >   Failed test:  4
> > >   Non-zero exit status: 1
> > > Files=17, Tests=250,  3 wallclock secs ( 0.07 usr  0.09 sys +  2.04 cusr  0.75 csys =  2.95 CPU)
> > > Result: FAIL
> > > Failed 1/17 test programs. 1/250 subtests failed.
> > > make[2]: *** [test_dynamic] Error 1
> > > Makefile:910: recipe for target 'test_dynamic' failed
> 
> This seems to be a fallout of the fix for CVE-2014-8139.
> With unzip_6.0-12+b1 the test passes.
> 
> With all fixed version of unzip we get (with some debug info):
> 
> unzip -t /tmp/testout-QsWDf.zip
> Archive:  /tmp/testout-QsWDf.zip
>     testing: META-INF/               bad extra-field entry:
>       EF block length (0 bytes) invalid (< 4)
>     testing: META-INF/MANIFEST.MF     OK
>     testing: tg/                      OK
> At least one error was detected in /tmp/testout-QsWDf.zip.

This also fails for me on wheezy, updating the metadata accordingly.

The test data source file is t/data/jar.zip, which also triggers the
same problem with 'unzip -t'. So Archive-Zip is just passing through
the problematic field.

I note that this is Debian specific as we add jar.zip in our patch for
#654899. Upstream Archive-Zip doesn't have a jar file in their test
suite at all.

Andrew Gallagher's comment in
 https://bugzilla.redhat.com/show_bug.cgi?id=1174844
is topical:

  I think this patch is causing "unzip -t" to now fail on executable
  JARs, which added the additional executable-jar extra field
  (http://stackoverflow.com/tags/executable-jar/info).

FWIW I get similar 'unzip -t' failures with lots of .jar
files on my system including jre system files like
/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/dnsns.jar .

I'm cc'ing unzip maintainer Santiago and the security team.
Do you think this is a regression in unzip that should be fixed, or
should we just work around it in libarchive-zip-perl (probably by
disabling the relevant test)?
-- 
Niko Tyni   ntyni at debian.org