Latest unzip update breaks programs dependent on unzip output

[Radu Cornea]

The latest version of unzip has a bug which moves the filename from the zip listing from last position to first. Therefore, any program that relies on parsing unzip output will fail to recognize it as a valid output. I first noticed this in mc. Example:

> unzip -v test.zip
Archive: test.zip
 Length Method Size Ratio Date Time CRC-32 Name
 -------- ------ ------- ----- ---- ---- ------ ----
 test.txt 32 Defl:N 30 6% 02-14-06 17:57 4ebb4896
 -------- ------- --- -------
      32 30 6% 1 file

> unzip -l test.zip
Archive: test.zip
  Length Date Time Name
 -------- ---- ---- ----
 test.txt 32 02-14-06 17:57
 -------- -------
       32 1 file

You can see that the headers are ok, but the 'name' field shows up where the 'length' should appear, instead of being last.
The bug was probably introduced by the change in the outputting function (from changelog):

  * unzpriv.h, Info macro:
    - Use snprintf() instead of sprintf() as inner formatting function.
    - Use fputs() instead of fprintf() as outer function to ignore leftover
      format strings which might not have been substituted in the inner
      snprintf().

[Loic Pefferkorn (loic)]

Confirmed.
For example, ark (kde archiver tool) can't list files inside a zip archive.

[Martin Pitt (pitti)]

Sorry, I didn't notice that. Will fix ASAP.

[Martin Pitt (pitti)]

 unzip (5.52-6ubuntu3) dapper; urgency=low
 .
   * Previous security update scrambled the output fields in the contents
     listing, fix that regression.

stables fixes will go out soon.

[Martin Pitt (pitti)]

fixed stables in USN-248-2.