[issue4871] zipfile can't decrypt

R. David Murray added the comment: 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. -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> clos

[issue4871] zipfile can't decrypt

R. David Murray added the comment: 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. --

[issue4871] zipfile can't decrypt

R. David Murray added the comment: 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 d

[issue4871] zipfile can't decrypt

STINNER Victor added the comment: Patch for py3k: str=>bytes, remove "u" string prefix and rename "bytes" variable to "data" to avoid conflict with the bytes type. Added file: http://bugs.python.org/file12729/zipfile_no_unicode_pasword-2-py3k.patch ___ Py

[issue4871] zipfile can't decrypt

STINNER Victor added the comment: gagenellina: Oops, yes, I wrote my patch for Python trunk. New patch only uses two checks for the password type (since extract() calls open()). I also changed the error message. -- versions: +Python 2.6, Python 2.7, Python 3.1 Added file: http://bugs.

[issue4871] zipfile can't decrypt

Gabriel Genellina added the comment: Yes, the unicode flag is irrelevant to the password. To successfuly decrypt a file, one must know the password *and* the encoding in use when it was written, so the only sensible thing to do is to accept bytes only. Your patch looks good to me with a few

[issue4871] zipfile can't decrypt

Changes by STINNER Victor : Added file: http://bugs.python.org/file12723/zipfile_no_unicode_pasword.patch ___ Python tracker ___ ___ Python-bug

[issue4871] zipfile can't decrypt

Changes by STINNER Victor : Removed file: http://bugs.python.org/file12722/zipfile_no_unicode_pasword.patch ___ Python tracker ___ ___ Python-b

[issue4871] zipfile can't decrypt

STINNER Victor added the comment: I created small archive with a password using zip 2.32 (Ubuntu Gutsy). The unicode flag is not set and so ASCII charset is used to encode the password. But my password was an unicode password using non-ASCII characters and so I get an UnicodeEncodeError ('asc

[issue4871] zipfile can't decrypt

Amaury Forgeot d'Arc added the comment: in Lib/zipfile.py, the filename is already allowed to be unicode if the "flag_bits" for the file entry contains 0x800. This indicates that the encoding is utf-8. We could do the same for the password. Attached is a tentative patch along this idea (for py3

[issue4871] zipfile can't decrypt

Gabriel Genellina added the comment: Lukas Lueg> The default encoding is UTF8 What do you mean? Not inside a zip file. The default encoding is CP437 (the original IBM PC US character set). A zipfile password is a sequence of bytes, not characters, as defined in the specification. Probably th

[issue4871] zipfile can't decrypt

Lukas Lueg added the comment: The default encoding is UTF8. Even without that there should be no problems while staying in the same environment as the character->translation is the same. However it violates the rule of least surprise to see zipfile throwing CRC errors because the password is so

[issue4871] zipfile can't decrypt

STINNER Victor added the comment: > check if 'password' is a unicode-object > and encode to default within zipfile. Hmmm... what is the default charset? :-) I think that the charset depends on the OS and the user locale... ___ Python tracker

[issue4871] zipfile can't decrypt

Lukas Lueg added the comment: 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 .encode() on all his strings (so 'password' is an instance of bytes and 'ch' an instance of int). I'd prefer that. Or to c

[issue4871] zipfile can't decrypt

Glade Diviney added the comment: In this case under test, the password string had been clipped from a filename, so I suppose it would have been Unicode. ___ Python tracker ___ __

[issue4871] zipfile can't decrypt

STINNER Victor added the comment: The key is a bytes string or an unicode string? Using bytes, each element is an int instead of a str. -- nosy: +haypo ___ Python tracker ___ __

[issue4871] zipfile can't decrypt

New submission from Glade Diviney : If a password is supplied using zpifile.read(objName, password), a TypeError occurs: File "C:\Program Files\Python30\lib\zipfile.py", line 420, in __init__ self._UpdateKeys(p) File "C:\Program Files\Python30\lib\zipfile.py", line 424, in _UpdateKeys