Repository navigation
zipfile password fails validation #45344
Description
| BPO | 1003 |
|---|---|
| Nosy | @gpshead |
| Files |
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']
Activity
djw commentedon Aug 23, 2007
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 =
1554440319ord(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 commentedon Aug 30, 2007
can you provide a test zip file demonstrating the problem?
djw commentedon Aug 30, 2007
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 commentedon Jan 19, 2008
this failure also occurs on simple zip files created using infozip's zip
with -e to "encrypt" the contents. debugging...
gpshead commentedon Jan 20, 2008
Fixed in r60121 (2.6). zip file decryption "check" bytes were more
complicated than the existing code supported. Algorithm updated.