[issue3016] tarfile.py incurs exception from self.chmod() when tarball has g+s

Lars Gustäbel [EMAIL PROTECTED] added the comment: With some effort I could reproduce the problem (on a FAT32 filesystem), but what we have here is clearly a usage problem. In unpack_tarfile() in setuptools/archive_util.py TarFile's internal _extract_member() method is used to extract

[issue2058] reduce tarfile memory footprint

Lars Gustäbel [EMAIL PROTECTED] added the comment: Checked into the py3k branch as r62337. -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2058

[issue2251] tarfile using nonexistent function

Lars Gustäbel added the comment: This is in fact misuse of the addfile() method on your side. The docs (http://docs.python.org/dev/library/tarfile.html#tarfile.TarFile.addfile) state that the first argument is supposed to be a TarInfo object not a pathname. You should use the add() method

[issue2058] reduce tarfile memory footprint

New submission from Lars Gustäbel: tarfile.py wastes lots of memory resources. The memory consumption does not depend on the size of an archive but on the numbers of members in it. The attached patch reduces memory usage by about 60% and consists of two independent strategies (each with about 30

[issue2004] tarfile extractall() allows local attacker to overwrite files while extracting

Lars Gustäbel added the comment: os.mkdir() and os.makedirs() always apply the current umask to the mode. We cannot be responsible for poorly chosen umasks. In general, tarfile and zipfile create directories with reasonable modes. So, IMO the zipfile-dirperm.diff is not needed and Michael's

[issue2004] tarfile extractall() allows local attacker to overwrite files while extracting

Lars Gustäbel added the comment: I took the liberty of applying my patches to the trunk (r60588) and the release25-maint branch (r60589). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2004

[issue2004] tarfile extractall() allows local attacker to overwrite files while extracting

Lars Gustäbel added the comment: This was fixed in the trunk in r53526 about a year ago following issue1507247. I did not backport it to 2.5 at that time, because it would have changed existing behaviour. If there are no objections I could do this now. The os.mkdir() call in TarFile.makedir

[issue1886] Permit to easily use distutils --formats=tar, gztar, bztar on all systems

Lars Gustäbel added the comment: Hm, on my Linux box both files are more or less identical. Sorry, I cannot reproduce your problem. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1886

[issue1527974] tarfile chokes on ipython archive on Windows

Lars Gustäbel added the comment: I close this issue because it is out of date. The new TarFile.extractall() method in Python 2.5 provides a way to solve the original problem IMO. -- resolution: - out of date status: open - closed _ Tracker [EMAIL

[issue1540385] tarfile __slots__ addition

Lars Gustäbel added the comment: I close this issue as there has been no progress over the last 1.5 year. -- resolution: - rejected status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1540385

[issue1735] tarfile.TarFile.extractall not setting directory permissions correctly

Changes by Lars Gustäbel: -- assignee: - lars.gustaebel nosy: +lars.gustaebel __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1735 __ ___ Python-bugs-list mailing list

[issue1735] tarfile.TarFile.extractall not setting directory permissions correctly

Lars Gustäbel added the comment: Committed to release25-maint branch as r59713. -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1735

[issue1735] tarfile.TarFile.extractall not setting directory permissions correctly

Lars Gustäbel added the comment: Thanks for the patch. I added a testcase and applied it to the trunk, see r59712. Python 2.5 follows later on. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1735

[issue1531] tarfile.open(fileobj=f) and bad metadata of the first file within the archive

Lars Gustäbel added the comment: I fixed this in the trunk (r59260) and release25-maint branch (r59261). Thanks for the report. If you cannot wait for the next release, I recommend you use mode r| as a workaround. BTW, 756 is absolutely no realistic example value for the position of the second

[issue1119] Search index is messed up after partial rebuilding

New submission from Lars Gustäbel: When rebuilding parts of the documentation the search index is emptied. The problem is that the extensions are not stripped from the filenames that are given to IndexBuilder.prune() method. Therefore, the Search widget on http://docs.python.org/dev/3.0

[issue1044] tarfile insecure pathname extraction

Lars Gustäbel added the comment: After careful consideration and a private discussion with Martin I do no longer think that we have a security issue here. tarfile.py does nothing wrong, its behaviour conforms to the pax definition and pathname resolution guidelines in POSIX. There is no known

[issue1044] tarfile insecure pathname extraction

Lars Gustäbel added the comment: I updated the documentation, r57764 (trunk) and r57765 (2.5). -- resolution: - works for me status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1044

[issue1044] tarfile insecure pathname extraction

New submission from Lars Gustäbel: tarfile does not check pathnames or linknames on extraction. This can lead to data loss or attack scenarios when members with absolute pathnames or pathnames outside of the archive's scope overwrite or overlay existing files or directories. Example

[issue1044] tarfile insecure pathname extraction

Lars Gustäbel added the comment: In principle I do not object, but this is a preliminary patch. I am still not happy with the naming of the check_paths argument. Also, the patch was made against the trunk which means that it contains hunks with the new reStructuredText documentation. Please

[issue1276378] tarfile: adding filed that use direct device addressing

Lars Gustäbel added the comment: Closing this due to lack of interest. This is no tarfile issue. If direct device addressing should be supported by Python, os.stat() would be the place to implement it. -- resolution: - wont fix status: open - closed

<    1   2   3