Repository navigation
unzip silently drops data after the first gzip member #496
Description
BazaRb::Compress#unzip stops after the first member of a valid gzip stream. RFC 1952 defines a gzip file as a sequence of members placed one after another, but Zlib::GzipReader#each(4096) returns only the first member's data here.
Steps to reproduce:
- Create two gzip members containing
firstandsecond. - Concatenate the compressed byte strings and pass them to
unzip.
Actual result: unzip returns first and drops second. I reproduced this with the current implementation's Zlib::GzipReader#each(4096) call.
Expected result: decompressing a valid concatenated gzip stream returns firstsecond.
Impact: BazaRb#download calls unzip on a gzip response body and treats a 200 response as complete after writing that result. If the response contains multiple valid members, the downloaded file is silently truncated.
Technical evidence: lib/baza-rb/compress.rb iterates one Zlib::GzipReader without checking or processing subsequent members. The format is defined in RFC 1952, section 2.2.
Activity
Vova4o commentedon Oct 1, 2026
Submitted #501 for review.
unzipnow reads all concatenated gzip members, preserving binary data and enforcing the existing uncompressed size limit across the combined output. Regression tests also cover empty members, the public download path, the exact limit, and corruption or truncation in later members. All six regressions fail on unchanged master and pass with the fix. The full local offline Rake build passes: 170 tests, 307 assertions, 99.13% coverage, standalone checks, RuboCop and YARD.All 12 CI checks pass, including the full Rake matrix on Ubuntu and macOS with Ruby 3.3 and 3.4.