Conversation
#940 resolved 0 to float("inf"), and for a list archive that value is the zip-bomb guard - the only bound on extraction. With the setting at 0 a small zip of zeros unpacked without limit. 0 stays "no limit" for files; a list archive falls back to max_list_text_size() * MAX_LISTS_PER_ARCHIVE (1 GB by default), which refuses nothing that would have been kept. The two assertions #940 dropped from the neighbouring test are back. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AP6LSxkr4n9dMFNSNMogmW
…e-list-zip-bomb-guard
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #945. This follows up my review on #940.
The problem: #940 resolved
MAX_FETCH_FILE_SIZE = 0tofloat("inf"). For a list archive, that value is the zip-bomb guard:_validate_zip_members()'s sum of declared sizes is the only bound on extraction.ZipExtFiletruncates each member to its declared size, and that size is now unbounded.max_list_text_size()is only checked after extraction.So with the setting at 0, a small zip of zeros unpacked without limit. Reproduced on main: an 8001-byte member against
MAX_LIST_TEXT_SIZE = 1000was extracted in full and only refused afterwards. v1.13.1 is not affected, because it predates #940.The fix: 0 still means "no limit" for files. For a list archive it now falls back to
max_list_text_size() * MAX_LISTS_PER_ARCHIVE, which is 1 GB with the defaults. Any list overmax_list_text_size()is refused after extraction anyway, so this refuses nothing that would have been kept. #940's live 482 MB SamothMetal case still passes the guard. The rejection message now names the ceiling that actually applied, instead of "MAX_FETCH_FILE_SIZE (0 bytes)".Tests (
tests/test_list_fetch.py):MAX_LIST_TEXT_SIZE, and a real cap is used as it is.test_a_declared_total_size_over_the_cap_is_rejected_before_extractingare restored.I mutation-checked four ways:
infagain, a fallback that ignoresMAX_LIST_TEXT_SIZE, 0 read as a zero-byte ceiling (#939 again), and the old message. Each one fails a test.Docs: both changelogs, the setting's help text, the
defaults.pycomment, and a regeneratedsettings.conf.sample.Suite: full suite green on this branch, and also merged with #942 and #944.
🤖 Generated with Claude Code
https://claude.ai/code/session_01AP6LSxkr4n9dMFNSNMogmW