classification
Title: zipfile.ZipFile overwrites files outside destination path
Type: security Stage: resolved
Components: Library (Lib) Versions: Python 3.2, Python 3.3, Python 3.4, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: serhiy.storchaka Nosy List: Arfrever, amaury.forgeotdarc, benjamin.peterson, catalin.iacob, georg.brandl, gregory.p.smith, larry, loewis, ned.deily, python-dev, r.david.murray, schmir, serhiy.storchaka, twb
Priority: release blocker Keywords: needs review, patch

Created on 2009-09-22 22:10 by schmir, last changed 2013-02-08 20:04 by Arfrever. This issue is now closed.

Files
File name Uploaded Description Edit
extract-doc.diff twb, 2009-09-29 22:36 Update to extract() method documentation
zipfile-6972-test.diff twb, 2009-09-30 06:14 test for directory escape
zipfile-6972-patch-2.diff twb, 2009-09-30 19:29 patch to zipfile module for directory escape, with fix for case sensitive file systems
zipfile_fix_arcname_3.patch serhiy.storchaka, 2012-10-23 18:19 Strip leading absolute name part and ".." components review
zipfile_fix_arcname_4-2.7.patch serhiy.storchaka, 2013-02-02 13:20 review
zipfile_fix_arcname_4-3.x.patch serhiy.storchaka, 2013-02-02 13:20 review
Messages (50)
msg93021 - (view) Author: Ralf Schmitt (schmir) Date: 2009-09-22 22:10
ZipFile.extractall happily overwrites any file on the filesystem. One
can put files with a name like "//etc/password" in a zip file and
extractall will overwrite /etc/password (with sufficient rights).

The docs say:

ZipFile.extractall([path[, members[, pwd]]])

    Extract all members from the archive to the current working
directory. path specifies a different directory to extract to. members
is optional and must be a subset of the list returned by namelist(). pwd
is the password used for encrypted files.


I read that as: it will put all files into path or a subdirectory.
Using names like "../../../etc/password" also leads to files being
written outside that path directory.
msg93251 - (view) Author: Thomas W. Barr (twb) Date: 2009-09-29 04:19
Do people have an opinion as to whether this should be fixed with a 
docfix, fixed as default (with option to allow path traversal) or fixed as 
a non-default option? The same issue exists in ZipFile.extract, but in 
that case you're presumably passing a path you've already vetted.

Either way, I'll write a test case for it tomorrow.
msg93268 - (view) Author: Ralf Schmitt (schmir) Date: 2009-09-29 09:46
I think this should clearly be fixed in the code. The current code tries
to handle absolute paths by removing the first slash (unfortunately not
the second), so it looks like it tries to be safe and only write to the
destination directory. That should be the default operation.
I even think that there should be *no* option to allow overriding files
outside the destination path (on unix one can always use / as
destination if he feels like overwriting his /etc/passwd)
The documentation should also mention that it's unsafe to use this
method in python <2.6.2.
msg93269 - (view) Author: Ralf Schmitt (schmir) Date: 2009-09-29 09:48
The documentation should also mention that it's unsafe to use this
method in python <= 2.6.2. 2.6.2 is also unsafe.
msg93278 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2009-09-29 11:02
The tarfile module solved this issue with a documentation warning:
http://docs.python.org/library/tarfile.html#tarfile.TarFile.extractall
msg93305 - (view) Author: Thomas W. Barr (twb) Date: 2009-09-29 17:20
My working solution is to iterate through members, and ensuring that
os.path.abspath(os.path.join(path, member)) always .startswith(path).
This seems like a better solution than trying to trap on a pattern in
the string. Presumably the same fix can be made to tarfile.

For what it's worth, OS X's BOMArchiveManager will place a file stored
as '../foo.txt' in the extract path, not the directory right outside it.

While we're on the topic, there may also be a bug in this, or the
tarfile package that would allow a malicious archive to extract a
symlink to an existing directory somewhere on the target machine, and
files extracted to that symlink. I haven't really thought that through,
but I'm sure that my fix won't correct that possible issue.
msg93330 - (view) Author: Thomas W. Barr (twb) Date: 2009-09-29 20:51
Uploading test.
msg93331 - (view) Author: Thomas W. Barr (twb) Date: 2009-09-29 20:53
Uploading patch. This actually should fix my theoretical symlink bug
since realpath() properly follows symlinks. The only thing that I
haven't been able to test is the behavior of realpath() on
case-insensitive operating systems. This should do the right thing, the
path should be normalized, but can someone confirm this?
msg93332 - (view) Author: Thomas W. Barr (twb) Date: 2009-09-29 21:10
As for the documentation, it might be a wise idea to up date the current
documentation to mention this issue, until the next release. I'm not
really sure what the process is for doing that, though...
msg93333 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2009-09-29 21:35
Patches to the docs, just like patches to the code (the docs are in the
Doc subdirectory).  Once committed, they get auto-generated and uploaded.
msg93334 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2009-09-29 21:58
Documentation note added (copied from tarfile) in trunk r75149, 
release26-maint r75150 (hopefully in time for 2.6.3 but thats up to 
Barry).
msg93336 - (view) Author: Thomas W. Barr (twb) Date: 2009-09-29 22:36
zf.extract() is unsafe for the same reason. My patch fixes this issue,
but we should mention the possible bug in the documentation there as
well. They do this for the similar bug in tarfile.

I've copy/pasted the mention in tarfile.extract() to zipfile.extract()
into the diff.
msg93349 - (view) Author: Thomas W. Barr (twb) Date: 2009-09-30 06:14
My apologies, I clicked the wrong button and deleted my test. There is no 
change in the newly uploaded one.
msg93372 - (view) Author: Thomas W. Barr (twb) Date: 2009-09-30 19:29
os.path.realpath() doesn't normalize case, so this could have issues on
Windows. The new patch should not.

The Mac version of os.path.normpath doesn't change the path, as per the
posix version, which isn't correct on HFS+, which is not case sensitive.
That's another bug for another ticket, though.
msg93374 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2009-09-30 20:03
"The Mac version of os.path.normpath doesn't change the path, as per the
posix version, which isn't correct on HFS+, which is not case sensitive."

Not so. Case-sensitive vs case-insensitive behavior is chosen when 
initializing an HFS+ file system (since OS X 10.3).
msg93375 - (view) Author: Thomas W. Barr (twb) Date: 2009-09-30 20:11
Good point, I'd forgotten that case-sensitive file systems are an
option. I do know that it's not the default, though, and that as shipped
from Apple, at least the consumer machines are case-insensitive. Things
may be different in server-land.

For what it's worth, NTFS isn't entirely case-insensitive, either.
(http://support.microsoft.com/kb/100625)

Should the os.path.normcase() method be made smarter, and actually query
the filesystem about such things? (If I should start a new ticket for
this, somebody please let me know.)
msg93376 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2009-09-30 21:29
Yes, as shipped from the factory, the default "root" file system is 
still case-insensitive but the user can change that.  There there are 
file systems on attached disk images and NFS-mounted file systems, etc 
etc.  More to the point, it's not a system attribute, rather it's a 
file-system attribute and, since a file system mount point can be almost 
anywhere in a directory structure, in general, you can't predict where 
you're going to encounter insensitive vs -sensitive behavior; it could 
vary from directory to directory.  But isn't dealing with case-
insensitive behavior just a special case of the general case of what 
extract/extractall do about overwriting existing files?  I don't see 
that addressed in the current docs.
msg93379 - (view) Author: Thomas W. Barr (twb) Date: 2009-09-30 22:41
A fair point. I was thinking that we could query the OS about whatever
filesystem the path is on, but this wouldn't work for a file that hasn't
been created yet.

The issue with extractall() isn't just that it can extract over existing
files, it's that it can write files anywhere on the filesystem, both by
exploiting symlinks and through path manipulation. The more I think
about it, though, the more I think the case sensitivity is a non-issue
here, since the trailing part of the extraction paths is built out of
the base path, which I then compare against. The capitalization will
therefore be consistent, and I don't need to worry about this. Does this
seem right?
msg93380 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2009-09-30 22:50
The patch won't work if the target file already exists as a symlink.

I think that such a check is not a good idea. Using symlinks to extract files 
to somewhere else may be a feature, after all.  Specially if the symlink 
already exists before the operation. Some real-case example:
  /home/xxx/bin   --> symlink to /someotherpath/bin
  /home/xxx/lib   --> symlink to /someotherpath/lib
Now I want to extract "lib/libXXX.so" into "/home/xxx"

I suggest to only update the documentation with a warning, similar to the one 
for the tarfile module.
msg93381 - (view) Author: Ralf Schmitt (schmir) Date: 2009-09-30 23:16
Adding a warning to the documentation is wrong. The intention of the
code clearly is to only create files in the destination directory (or
why remove the first slash then?) and that is also the impression I get
from reading the documentation.
msg93382 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2009-09-30 23:37
Adding a warning to the documentation is not wrong, it is the only thing 
that is possible for the 2.6.3 release.  Its too late in the current 
release process to change code.
msg93396 - (view) Author: Ralf Schmitt (schmir) Date: 2009-10-01 10:11
I'd rather have an extractall version which just throws a RuntimeError
than one which overwrites any file with any content on my filesystem if
I'm trying to unzip a zip file.  Then I at least know that I have to
write my own version. Adding a warning to the documentation instead of
fixing that bug was wrong for the tarfile module and is wrong for the
zipfile module. The "release process" disagrees with me here, but I'd
still call that wrong.
msg93420 - (view) Author: Thomas W. Barr (twb) Date: 2009-10-01 20:13
Even if we can't fix things for this release, presumably it's not too
late to fix things for 2.7, right?

Yes, there certainly are cases where you might want to have creative
usage of symlinks and stored paths to allow overwriting existing files,
and placing files outside of the extraction path, but that doesn't seem
like the default case to me. Would it be a decent compromise to add a
extract_under_path=True default option to extract() and extractall() for
2.7?
msg93426 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2009-10-02 00:55
yes this will be fixed in 2.7/3.2.

as for creative uses where someone might want the out of supplied path 
overwriting behavior?  those people are insane and should be made to jump 
through extra hoops to get it. ;)
msg157763 - (view) Author: Thomas W. Barr (twb) Date: 2012-04-07 23:01
I'll update my patch to work on the current 3.x head later tonight.
msg157778 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-04-08 06:56
> +        # make sure the zip file isn't traversing out of the path
> +        if not targetpath.startswith(basepath):

Check is insufficient. basepath='/etc/asd', member.filename='../asdfgh'.

The issue10905 has relations with this issue.

P. S. Viewing patches in this issue is not working.
msg157789 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-04-08 14:28
To clarify what Serhiy said about the patches, the link to the patch works, but the Reitveld review button isn't working.  I get 'No issue exists with that id (6972)'.
msg173526 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-10-22 15:00
Here is a patch based on patch for issue10905. Test included (I have removed some old tests as new one supersede them). Please test on Windows.

".." components, leading slashes, drive letter, etc are just dropped, as in unzip or 7-Zip. Thanks Zhigang Wang for original patch and research.
msg173567 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-10-22 21:58
Oh, I forgot docs.
msg173630 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-10-23 18:19
Patch updated. Fixed case '../C:/foo' on Windows.
msg180681 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-01-26 16:22
Can anyone review the patch?
msg181055 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2013-02-01 02:59
the patch looks good, thanks!  one minor comment in a test but i'll take care of that as i submit.
msg181072 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-02-01 09:16
Feel free to change the patch as you see fit.
msg181102 - (view) Author: Roundup Robot (python-dev) Date: 2013-02-01 19:40
New changeset 0c5fa35c9f12 by Gregory P. Smith in branch '3.2':
Fixes Issue #6972: The zipfile module no longer overwrites files outside of
http://hg.python.org/cpython/rev/0c5fa35c9f12

New changeset 483488a1dec5 by Gregory P. Smith in branch '3.3':
Fixes Issue #6972: The zipfile module no longer overwrites files outside of
http://hg.python.org/cpython/rev/483488a1dec5

New changeset 249e0b47b686 by Gregory P. Smith in branch 'default':
Fixes Issue #6972: The zipfile module no longer overwrites files outside of
http://hg.python.org/cpython/rev/249e0b47b686

New changeset 4d1948689ee1 by Gregory P. Smith in branch '2.7':
Fixes Issue #6972: The zipfile module no longer overwrites files outside of
http://hg.python.org/cpython/rev/4d1948689ee1
msg181106 - (view) Author: Ralf Schmitt (schmir) Date: 2013-02-01 21:07
does anyone know if the same issue has been fixed in the tarfile module?
msg181134 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2013-02-02 06:03
yes, tarfile appears to have the same problem.  http://bugs.python.org/issue17102 filed.
msg181158 - (view) Author: Roundup Robot (python-dev) Date: 2013-02-02 10:31
New changeset c3ab8a698d2f by Serhiy Storchaka in branch '2.7':
Fix translating of illegal characters on Windows (issue #6972).
http://hg.python.org/cpython/rev/c3ab8a698d2f
msg181159 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2013-02-02 11:07
The patch introduced a Cyrillic "C" into the docs, see below.  This makes the LaTeX build fail.

+      ``foo/bar`` on Unix, and ``С:\foo\bar`` becomes ``foo\bar`` on Windows.
                                  ^^
msg181161 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-02-02 11:18
There are different test fails on Windows:

http://buildbot.python.org/all/builders/x86%20XP-5%203.3/builds/405/steps/test/logs/stdio
======================================================================
ERROR: test_extract_hackers_arcnames (test.test_zipfile.TestsWithSourceFile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.3.moore-windows\build\lib\test\test_zipfile.py", line 585, in test_extract_hackers_arcnames
    writtenfile = zipfp.extract(arcname, targetpath)
  File "D:\Buildslave\3.3.moore-windows\build\lib\zipfile.py", line 1212, in extract
    return self._extract_member(member, path, pwd)
  File "D:\Buildslave\3.3.moore-windows\build\lib\zipfile.py", line 1253, in _extract_member
    os.makedirs(upperdirs)
  File "D:\Buildslave\3.3.moore-windows\build\lib\os.py", line 269, in makedirs
    mkdir(name, mode)
FileNotFoundError: [WinError 3] The system cannot find the path specified: 'target\\subdir\\subsub\\foo'

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.3/builds/428/steps/test/logs/stdio
======================================================================
FAIL: test_extract_hackers_arcnames (test.test_zipfile.TestsWithSourceFile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.3.kloth-win64\build\lib\test\test_zipfile.py", line 586, in test_extract_hackers_arcnames
    self.assertEqual(writtenfile, correctfile)
AssertionError: 'target\\subdir\\subsub' != 'target\\subdir\\subsub\\foo\\bar'
- target\subdir\subsub
+ target\subdir\subsub\foo\bar
?                     ++++++++
msg181162 - (view) Author: Roundup Robot (python-dev) Date: 2013-02-02 11:30
New changeset b6b707063991 by Serhiy Storchaka in branch '2.7':
Fix a Cyrillic "C" inroduced into the docs by patch for issue #6972.
http://hg.python.org/cpython/rev/b6b707063991

New changeset ede0f27988f2 by Serhiy Storchaka in branch '3.2':
Fix a Cyrillic "C" inroduced into the docs by patch for issue #6972.
http://hg.python.org/cpython/rev/ede0f27988f2

New changeset 785b8b49c3bf by Serhiy Storchaka in branch '3.3':
Fix a Cyrillic "C" inroduced into the docs by patch for issue #6972.
http://hg.python.org/cpython/rev/785b8b49c3bf

New changeset 25294188c4ea by Serhiy Storchaka in branch 'default':
Fix a Cyrillic "C" inroduced into the docs by patch for issue #6972.
http://hg.python.org/cpython/rev/25294188c4ea
msg181163 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-02-02 11:31
> The patch introduced a Cyrillic "C" into the docs, see below.

Thank you. Fixed.
msg181166 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-02-02 13:20
Here are patches which possible fixes some of this failures.
msg181171 - (view) Author: Roundup Robot (python-dev) Date: 2013-02-02 15:47
New changeset ebef003a2acd by Serhiy Storchaka in branch '2.7':
Fix the test and remove trailing dots on Windows for issue #6972.
http://hg.python.org/cpython/rev/ebef003a2acd
msg181178 - (view) Author: Roundup Robot (python-dev) Date: 2013-02-02 16:35
New changeset 5a68052b52ea by Serhiy Storchaka in branch '2.7':
Preserve backslashes in malicious zip files for testing issue #6972.
http://hg.python.org/cpython/rev/5a68052b52ea
msg181183 - (view) Author: Roundup Robot (python-dev) Date: 2013-02-02 17:26
New changeset ab4b8da79a5f by Serhiy Storchaka in branch '2.7':
Fix test for issue #6972.
http://hg.python.org/cpython/rev/ab4b8da79a5f
msg181188 - (view) Author: Roundup Robot (python-dev) Date: 2013-02-02 17:54
New changeset 434b50c7bbed by Serhiy Storchaka in branch '3.2':
Fix the test for issue #6972.
http://hg.python.org/cpython/rev/434b50c7bbed

New changeset 8b33f3a4a200 by Serhiy Storchaka in branch '3.3':
Fix the test for issue #6972.
http://hg.python.org/cpython/rev/8b33f3a4a200

New changeset 7a47fd7f2fdc by Serhiy Storchaka in branch 'default':
Fix the test for issue #6972.
http://hg.python.org/cpython/rev/7a47fd7f2fdc
msg181244 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2013-02-03 06:12
I believe this is all done after Serhiy's fixes.
msg181646 - (view) Author: Catalin Iacob (catalin.iacob) * Date: 2013-02-07 21:37
There are 2 issues with the documentation changes introduced by these patches.

1. for 2.7, the note added by the doc patch is in the wrong place, at the setpassword method instead of the extract or extractall method

2. for 3.x the "Never extract archives from untrusted sources..." warning got removed but it's still useful for users that read the documentation online and therefore get the updated docs but haven't updated Python to the latest patch release and therefore don't have the fix. For example, anybody reading the docs for 3.2 or 3.3 today doesn't see that extractall is dangerous and there is no released Python containing the fix so by all practical means extractall is still dangerous today.

To address point 2, I think the warning should be kept with an extra mention regarding exact version where it got fixed so that, when reading the documentation, everybody can assess exactly whether extractall is safe for them to use or not.

I can't reopen the bug since I don't have tracker privileges but since it's a security issue I think it's important for these to get addressed.
msg181647 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2013-02-07 21:54
reopening as documentation mixups remain to be fixed.
msg181659 - (view) Author: Roundup Robot (python-dev) Date: 2013-02-08 06:18
New changeset d73fb6b06891 by Gregory P. Smith in branch '2.7':
Issue #6972: fix the documentation mis applied patch.
http://hg.python.org/cpython/rev/d73fb6b06891

New changeset 1c2d41850147 by Gregory P. Smith in branch '3.2':
Issue #6972: keep the warning about untrusted extraction and mention
http://hg.python.org/cpython/rev/1c2d41850147

New changeset 5fbca37de9b1 by Gregory P. Smith in branch '3.3':
Issue #6972: keep the warning about untrusted extraction and mention
http://hg.python.org/cpython/rev/5fbca37de9b1

New changeset f5e3f2f0fe79 by Gregory P. Smith in branch 'default':
Issue #6972: keep the warning about untrusted extraction and mention
http://hg.python.org/cpython/rev/f5e3f2f0fe79
History
Date User Action Args
2013-02-08 20:04:05Arfreversetstage: needs patch -> resolved
2013-02-08 06:19:09gregory.p.smithsetstatus: open -> closed
resolution: fixed
2013-02-08 06:18:35python-devsetmessages: + msg181659
2013-02-07 21:54:28gregory.p.smithsetpriority: high -> release blocker

nosy: + benjamin.peterson, larry
messages: + msg181647

resolution: fixed -> (no value)
stage: patch review -> needs patch
2013-02-07 21:52:49r.david.murraysetstatus: closed -> open
2013-02-07 21:37:22catalin.iacobsetmessages: + msg181646
2013-02-03 06:12:45gregory.p.smithsetstatus: open -> closed
assignee: gregory.p.smith -> serhiy.storchaka
messages: + msg181244
2013-02-03 04:30:32Arfreversetnosy: + Arfrever
2013-02-02 17:54:15python-devsetmessages: + msg181188
2013-02-02 17:26:54python-devsetmessages: + msg181183
2013-02-02 16:35:41python-devsetmessages: + msg181178
2013-02-02 15:47:15python-devsetmessages: + msg181171
2013-02-02 13:20:41serhiy.storchakasetfiles: + zipfile_fix_arcname_4-2.7.patch, zipfile_fix_arcname_4-3.x.patch

messages: + msg181166
2013-02-02 11:31:17serhiy.storchakasetmessages: + msg181163
2013-02-02 11:30:28python-devsetmessages: + msg181162
2013-02-02 11:18:08serhiy.storchakasetmessages: + msg181161
2013-02-02 11:07:17georg.brandlsetstatus: closed -> open
nosy: + georg.brandl
messages: + msg181159

2013-02-02 10:31:30python-devsetmessages: + msg181158
2013-02-02 06:03:08gregory.p.smithsetmessages: + msg181134
2013-02-01 21:07:14schmirsetmessages: + msg181106
2013-02-01 19:41:20gregory.p.smithsetstatus: open -> closed
resolution: fixed
2013-02-01 19:40:31python-devsetnosy: + python-dev
messages: + msg181102
2013-02-01 09:16:40serhiy.storchakasetmessages: + msg181072
2013-02-01 02:59:46gregory.p.smithsetmessages: + msg181055
2013-01-31 21:00:58catalin.iacobsetnosy: + catalin.iacob
2013-01-26 16:22:15serhiy.storchakasetmessages: + msg180681
2012-10-24 08:56:25serhiy.storchakasetstage: patch review
2012-10-23 18:19:18serhiy.storchakasetfiles: + zipfile_fix_arcname_3.patch

messages: + msg173630
2012-10-23 18:18:25serhiy.storchakasetfiles: - zipfile_fix_arcname_2.patch
2012-10-22 21:58:07serhiy.storchakasetfiles: + zipfile_fix_arcname_2.patch

messages: + msg173567
2012-10-22 21:57:30serhiy.storchakasetfiles: - zipfile_fix_arcname_2.patch
2012-10-22 15:00:59serhiy.storchakasetfiles: + zipfile_fix_arcname_2.patch
versions: + Python 3.4
messages: + msg173526

keywords: + needs review
stage: needs patch -> (no value)
2012-10-22 14:44:47serhiy.storchakalinkissue10905 superseder
2012-04-08 14:28:05r.david.murraysetnosy: + loewis
messages: + msg157789
2012-04-08 06:56:47serhiy.storchakasetmessages: + msg157778
2012-04-07 23:01:13twbsetmessages: + msg157763
2012-04-07 20:52:00pitrousetpriority: normal -> high
stage: needs patch
versions: + Python 3.3, - Python 2.6
2012-04-07 18:53:46serhiy.storchakasetnosy: + serhiy.storchaka
2009-10-02 00:55:44gregory.p.smithsetversions: + Python 2.7, Python 3.2
2009-10-02 00:55:32gregory.p.smithsetmessages: + msg93426
2009-10-01 20:13:20twbsetmessages: + msg93420
2009-10-01 10:11:11schmirsetmessages: + msg93396
2009-09-30 23:37:04gregory.p.smithsetmessages: + msg93382
2009-09-30 23:16:41schmirsetmessages: + msg93381
2009-09-30 22:50:48amaury.forgeotdarcsetmessages: + msg93380
2009-09-30 22:41:26twbsetmessages: + msg93379
2009-09-30 21:29:41ned.deilysetmessages: + msg93376
2009-09-30 20:11:35twbsetmessages: + msg93375
2009-09-30 20:03:52ned.deilysetnosy: + ned.deily
messages: + msg93374
2009-09-30 19:30:02twbsetfiles: - zipfile-6972-patch.diff
2009-09-30 19:29:50twbsetfiles: + zipfile-6972-patch-2.diff

messages: + msg93372
2009-09-30 06:14:01twbsetfiles: + zipfile-6972-test.diff

messages: + msg93349
2009-09-30 06:11:11twbsetfiles: - zipfile-6972-test.diff
2009-09-29 22:36:23twbsetfiles: + extract-doc.diff

messages: + msg93336
2009-09-29 21:58:53gregory.p.smithsetmessages: + msg93334
2009-09-29 21:35:15r.david.murraysetnosy: + r.david.murray
messages: + msg93333
2009-09-29 21:10:11twbsetmessages: + msg93332
2009-09-29 20:59:19gregory.p.smithsetpriority: normal
assignee: gregory.p.smith

nosy: + gregory.p.smith
2009-09-29 20:53:16twbsetfiles: + zipfile-6972-patch.diff

messages: + msg93331
2009-09-29 20:51:33twbsetfiles: + zipfile-6972-test.diff
keywords: + patch
messages: + msg93330
2009-09-29 17:20:08twbsetmessages: + msg93305
2009-09-29 11:02:03amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg93278
2009-09-29 09:48:02schmirsetmessages: + msg93269
2009-09-29 09:46:02schmirsetmessages: + msg93268
2009-09-29 04:19:37twbsetmessages: + msg93251
2009-09-29 00:19:59twbsetnosy: + twb
2009-09-22 22:11:34schmirsettitle: zipfile.ZipFile -> zipfile.ZipFile overwrites files outside destination path
2009-09-22 22:10:50schmircreate