Repository navigation
Feature: provide (safe) traversal/extraction facilities for zipfile.Path #123727
Description
zipfile.Path could provide its own traversal that could offer some safety checks.
Something like that might be nice. Though perhaps it could be more generic instead of being part of zipfile.Path, even if zipfile.Path would then perhaps provide an extraction API using that?
Originally posted by @obfusk in #123270 (comment)
Activity
[-]Feature: provide (safe) traversal facilities for `zipfile.Path`[/-][+]Feature: provide (safe) traversal/extraction facilities for `zipfile.Path`[/+]jaraco commentedon Sep 5, 2024
As mentioned in that issue, there does already exist one extraction API in
importlib.resources.as_file, although that implementation is written to create a temporary context. It also has certain limitations, such as it can extract a single file or directory, but not a set of files in a directory, and there's no facility to filter content in subdirectories.One thing to be careful about when extracting is that using
mkdir(exists_ok=True)could lead to traversal outside the target directory (e.g. if the zip file contains../../../etc/passwd).Before we embark on any implementation, let's first capture what are the motivations, use-cases, and requirements for such a feature? Who would use it and how?
rruuaanng commentedon Sep 7, 2024
For example, returning a list after calling, right？
jaraco commentedon Sep 7, 2024
Perhaps. We're looking for more complete user stories. For example:
That's a contrived user story as an illustration. What I want are real user stories from users who have legitimate use-cases that aren't met by the current
zipfile.Pathandimportlib.resources.as_filefunctionality.obfusk commentedon Sep 7, 2024
Being able to combine
.glob()and extract seems potentially useful to me.FYI: I just noticed
.glob()does not seem to be documented.jaraco commentedon Mar 8, 2025
If someone implements such a thing, let's not forget to remove the (recently contributed) note in the docs.