New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zipfile can't decrypt #49121
Comments
If a password is supplied using zpifile.read(objName, password), a File "C:\Program Files\Python30\lib\zipfile.py", line 420, in __init__ This is resolved in zipfile.py by replacing this line in __init__: |
The key is a bytes string or an unicode string? Using bytes, each |
In this case under test, the password string had been clipped from a |
This is basically the same problem as with other bytes-orientated modules. The choice is either to reject unicode and force the caller to use Or to check if 'password' is a unicode-object and encode to default |
Hmmm... what is the default charset? :-) I think that the charset |
The default encoding is UTF8. Even without that there should be no However it violates the rule of least surprise to see zipfile throwing |
Lukas Lueg> The default encoding is UTF8 What do you mean? Not inside a zip file. The default encoding is CP437 A zipfile password is a sequence of bytes, not characters, as defined |
in Lib/zipfile.py, the filename is already allowed to be unicode if the We could do the same for the password. Attached is a tentative patch |
I created small archive with a password using zip 2.32 (Ubuntu Gutsy). If I encode the unicode password to bytes using |
Yes, the unicode flag is irrelevant to the password. To successfuly Your patch looks good to me with a few comments:
|
gagenellina: Oops, yes, I wrote my patch for Python trunk. New patch |
Patch for py3k: str=>bytes, remove "u" string prefix and |
What about bytearray? Apparently that works pre-patch for at least read, though setpassword rejects it via an assertion. Also, the error message should be "expected bytes" rather than "bytes expected". Don't ask me why, that's just the way it is normally done, so the other order sounds weird to this English speaker's ear. Otherwise the py3k patch looks good and tests correctly for me. |
Thinking about this some more, it seems like the chance that someone is using bytearray to pass a password to zipfile is vanishingly small, especially since in non-optimized mode setpassword would have rejected it. So I think that this should go in. |
Committed in r87430 (with message word order change), backported to 3.1 in r87431. Making the parallel change to 2.7 would be likely to break working code, IMO. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: