zipfile password fails validation

[djw]

BPO	1003
Nosy	@gpshead
Files	exZipFile.zip

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/gpshead'
closed_at = <Date 2008-01-20.01:26:10.949>
created_at = <Date 2007-08-23.20:53:16.839>
labels = ['type-bug', 'library']
title = 'zipfile password fails validation'
updated_at = <Date 2008-01-20.01:26:10.935>
user = 'https://bugs.python.org/djw'

bugs.python.org fields:

activity = <Date 2008-01-20.01:26:10.935>
actor = 'gregory.p.smith'
assignee = 'gregory.p.smith'
closed = True
closed_date = <Date 2008-01-20.01:26:10.949>
closer = 'gregory.p.smith'
components = ['Library (Lib)']
creation = <Date 2007-08-23.20:53:16.839>
creator = 'djw'
dependencies = []
files = ['8361']
hgrepos = []
issue_num = 1003
keywords = []
message_count = 5.0
messages = ['55210', '55462', '55514', '60250', '60252']
nosy_count = 2.0
nosy_names = ['gregory.p.smith', 'djw']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue1003'
versions = ['Python 2.6']

[djw]

This is in python2.5: zipfile.py SVN rev-56308
When testing a zipfile.Zipfile().read() with a password protected zip
file, I would continually get exceptions. So I tracked this down to
line 796-797:
if ord(h[11]) != ((zinfo.CRC>>24)&255):
raise RuntimeError, "Bad password for file %s" % name

scope related data:
bytes = )¶G\x02ùû¬&\x1E#çÕ
h[11] = ¯
zinfo.CRC = 1554440319

ord(h[11]) == 175
((zinfo.CRC>>24)&255) == 92

When I commented out the error check, the script extracted 150 JPGs with
no corruption or errors in any of the images...so its just seems like an
issue with the error check.

[gpshead]

can you provide a test zip file demonstrating the problem?

[djw]

PW: 13*CrC!x

Verified again that this causes the false exception. Waiting on the
data vendor to give me more info about the file and what is used to
create it.

[gpshead]

this failure also occurs on simple zip files created using infozip's zip
with -e to "encrypt" the contents. debugging...

[gpshead]

Fixed in r60121 (2.6). zip file decryption "check" bytes were more
complicated than the existing code supported. Algorithm updated.