Bug 758631

Summary: file command can't identify the zip64 format correctly.
Product: Red Hat Enterprise Linux 5 Reporter: Karel Srot <ksrot>
Component: fileAssignee: Jan Kaluža <jkaluza>
Status: CLOSED ERRATA QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: low Docs Contact:
Priority: low    
Version: 5.7CC: jjaburek
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: file-4.17-22 Doc Type: Bug Fix
Doc Text:
Cause: File didn't contain magic pattern to detect zip64 (zip 3.0) files. Consequence: Archives in zip64 format was not detected. Fix: New magic pattern to detect the zip64 format has been added. Result: File now detects zip64 as excepted.
Story Points: ---
Clone Of: 637782 Environment:
Last Closed: 2012-06-22 09:44:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Karel Srot 2011-11-30 09:53:32 UTC
on RHEL5 file says:

# rpm -q file
file-4.17-19
# file /tmp/zip_archive_v3.zip 
/tmp/zip_archive_v3.zip: 

On the other hand, RHEL5 zip produces zip v2.3, therefore this is not a big deal such as on RHEL6.

+++ This bug was initially created as a clone of Bug #637782 +++

Description of problem:
file command can't identify the zip64 format correctly.

Version-Release number of selected component (if applicable):
zip-3.0-1.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. Create an archive as zip v3.0 format. 
$ echo foo | zip > test.zip 

2. Check a file type of the created archive by the file command. 
$ file test.zip 

Actual results:
The file command identifies a zip64 format archive as "data". 

Expected results:
The file command identifies a zip64 format archive as "ZIP64 archive data". 

Additional info:
magic bit from zip file 

50 4B 03 04  14 < -- correctly identified    --> PK...
50 4B 03 04  2D <-- incorrectly identified --> PK..-

From magic definition file
# ZIP archives (Greg Roelofs, c/o zip-bugs.edu)
0       string          PK\003\004
>30     ubelong         !0x6d696d65
...
>>4     byte            0x14            Zip archive data, at least v2.0 to extract
!:mime  application/zip
<-- add here
>>4     byte            0x2d            Zip64 archive data, at least v3.0 to extract
!:mime  application/zip


Adding 2d to the list here should fix this.  2D is used to identify "zip64" format. This issue can also be triggered

Comment 4 Jan Kaluža 2012-05-14 09:13:04 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: File didn't contain magic pattern to detect zip64 (zip 3.0) files.

Consequence: Archives in zip64 format was not detected.

Fix: New magic pattern to detect the zip64 format has been added.

Result: File now detects swap on zip64 as excepted.

Comment 5 Jan Kaluža 2012-05-14 09:16:01 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -4,4 +4,4 @@
 
 Fix: New magic pattern to detect the zip64 format has been added.
 
-Result: File now detects swap on zip64 as excepted.+Result: File now detects zip64 as excepted.

Comment 8 errata-xmlrpc 2012-06-22 09:44:30 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-1029.html