This follows up my review on #940, which merged before the review was addressed.
#940 made list_fetch._fetch_file_size_budget() return float("inf") when MAX_FETCH_FILE_SIZE = 0. That fixed #939, where "no limit" was being read as a zero-byte ceiling. But for a list archive, that budget is the zip-bomb guard:
_validate_zip_members() sums every member's declared file_size against it. This is the only bound on extraction._extract_member()'s own docstring says its running check is inert, because ZipExtFile truncates each member to what it declares, and there is no longer any cap on what can be declared.max_list_text_size() is only checked after everything has been extracted.
So with MAX_FETCH_FILE_SIZE = 0, a small list zip full of zeros unpacks without limit. Deflate compresses zeros about 1000:1, so the default 10 MB MAX_FETCH_LIST_FILE_SIZE lets through about 10 GB on disk. With MAX_FETCH_LIST_FILE_SIZE = 0 as well, which is the #937 operator's setting, there is no bound at all. That affects every list fetch, including the automatic refresh and automatic grabbing.
Reproduced on main (8b8e89f): MAX_FETCH_FILE_SIZE = 0, MAX_LIST_TEXT_SIZE = 1000, and a list zip with an 8001-byte member. The whole archive is extracted and only then refused: the extracted list is 8001 bytes, over the 1000-byte ceiling. The zip-bomb guard never ran.
Also: #940's new test deleted the last two assertions of test_a_declared_total_size_over_the_cap_is_rejected_before_extracting (no registry entry left behind, no extract dir left behind).
Fix: 0 stays "no limit" for files. For a list archive, the budget falls back to what real lists can hold: max_list_text_size() * MAX_LISTS_PER_ARCHIVE, which is 1 GB with the defaults. Any list over max_list_text_size() is rejected after extraction anyway, so this refuses nothing that is accepted today. #940's live SamothMetal case (482 MB uncompressed) still passes the guard. The rejection message will name the ceiling that applied, and the two assertions will be restored.
This follows up my review on #940, which merged before the review was addressed.
#940 made
list_fetch._fetch_file_size_budget()returnfloat("inf")whenMAX_FETCH_FILE_SIZE = 0. That fixed #939, where "no limit" was being read as a zero-byte ceiling. But for a list archive, that budget is the zip-bomb guard:_validate_zip_members()sums every member's declaredfile_sizeagainst it. This is the only bound on extraction._extract_member()'s own docstring says its running check is inert, becauseZipExtFiletruncates each member to what it declares, and there is no longer any cap on what can be declared.max_list_text_size()is only checked after everything has been extracted.So with
MAX_FETCH_FILE_SIZE = 0, a small list zip full of zeros unpacks without limit. Deflate compresses zeros about 1000:1, so the default 10 MBMAX_FETCH_LIST_FILE_SIZElets through about 10 GB on disk. WithMAX_FETCH_LIST_FILE_SIZE = 0as well, which is the #937 operator's setting, there is no bound at all. That affects every list fetch, including the automatic refresh and automatic grabbing.Reproduced on main (8b8e89f):
MAX_FETCH_FILE_SIZE = 0,MAX_LIST_TEXT_SIZE = 1000, and a list zip with an 8001-byte member. The whole archive is extracted and only then refused:the extracted list is 8001 bytes, over the 1000-byte ceiling. The zip-bomb guard never ran.Also: #940's new test deleted the last two assertions of
test_a_declared_total_size_over_the_cap_is_rejected_before_extracting(no registry entry left behind, no extract dir left behind).Fix: 0 stays "no limit" for files. For a list archive, the budget falls back to what real lists can hold:
max_list_text_size() * MAX_LISTS_PER_ARCHIVE, which is 1 GB with the defaults. Any list overmax_list_text_size()is rejected after extraction anyway, so this refuses nothing that is accepted today. #940's live SamothMetal case (482 MB uncompressed) still passes the guard. The rejection message will name the ceiling that applied, and the two assertions will be restored.