[issue40763] zipfile.extractall is safe by now
New submission from Va : In documentation of all Python 3 versions, [ZipFile.extractall](https://docs.python.org/3/library/zipfile.html#zipfile.ZipFile.extractall) states with a big red warning: > Warning > Never extract archives from untrusted sources without prior inspection. It is > possible that files are created outside of path, e.g. members that have > absolute filenames starting with "/" or filenames with two dots "..". This > module attempts to prevent that. See extract() note. However, when looking at the implementation, it calls _extract_member() which seems to sanitize filenames. So the warning might not be relevant anymore. Furthermore, when looking at [Python 2](https://docs.python.org/2/library/zipfile.html#zipfile.ZipFile.extractall) documentation, we can see the same warning, along with a change note: > Changed in version 2.7.4: The zipfile module attempts to prevent that. See > extract() note. So, the big red warning in Python 3 documentation might be relevant only for Python < 2.7.4, not for any Python 3 version. -- assignee: docs@python components: Documentation messages: 369854 nosy: VA, docs@python priority: normal severity: normal status: open title: zipfile.extractall is safe by now type: behavior versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40763] zipfile.extractall is safe by now
Va added the comment: > It is not obvious to me that zipfile._extract_member() together with (for windows) zipfile._sanitize_windows_name() have handled everything that could happen. What hasn't been handled then? What is the safe way to use it? I think documenting "this function is unsafe" without suggesting a replacement or a safe way to use it isn't very constructive: as a developer, I want to extract a zip archive, but the only function supposed to do the job tells me "this is unsafe". Ok, so what am I supposed to do to be safe? That's what documentation should tell me, not let me puzzled with doubt. > May I suggest that out of caution we leave it as it is? I don't think the situation should stay like this. - either the documentation should be more precise on what are the problems that can occur, and how to handle those problems - or better, the function should be fixed and made fully safe, so all programs using it are safe (and the warning can be removed) -- ___ Python tracker <https://bugs.python.org/issue40763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40763] zipfile.extractall is safe by now?
Change by Va : -- components: +Library (Lib) title: zipfile.extractall is safe by now -> zipfile.extractall is safe by now? type: behavior -> security ___ Python tracker <https://bugs.python.org/issue40763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40059] Provide a toml module in the standard library
Va added the comment: 1.0.0-rc.1 is out by now: https://github.com/toml-lang/toml/blob/master/CHANGELOG.md -- nosy: +VA versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue40059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32768] object.__new__ does not accept arguments if __bases__ is changed
New submission from VA : object.__new__ takes only the class argument, but it still accepts extra arguments if a class doesn't override __new__, and rejects them otherwise. (This is because __new__ will receive the same arguments as __init__ but __new__ shouldn't need to be overridden just to remove args) However, if a class has a custom __new__ at one point (in a parent class), and at a later point __bases__ is changed, object.__new__ will still reject arguments, although __new__ may not be overridden anymore at that point. See attached file. I can't check with all Python 3 versions, but the same code works fine in Python 2. -- files: bases.py messages: 311622 nosy: VA priority: normal severity: normal status: open title: object.__new__ does not accept arguments if __bases__ is changed type: behavior versions: Python 3.6 Added file: https://bugs.python.org/file47425/bases.py ___ Python tracker <https://bugs.python.org/issue32768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32768] object.__new__ does not accept arguments if __bases__ is changed
VA added the comment: The use case is a little more complex. I have a plugin system, with abstract interfaces. Plugins can't import each other, but plugins should be able to allowed to depend on another plugin (using string codes, still no direct imports), and even subclass another plugin's classes (and override some of their methods). In the sample code, A and C would be 2 plugins, and B would be a helper class (with string code parameters) whose purpose is to make a temporary bridge between A and C. A should work standalone. C would use A's code but could reimplement some of A's methods. B is a internal class that has A and C at hand, and changes C's __bases__ to point to A. I have been suggested other solutions, like using composition (a C instance would have an "a" field pointing to an A instance) to avoid inheritance altogether, or using the "type()" function in B.__new__ to create a custom class inheriting A. None of these solutions are really satisfying because they prevent C from using "super(...)" to refer to A methods. Rebinding __class__ simply does not allow to override methods at all. -- ___ Python tracker <https://bugs.python.org/issue32768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
