This is a patch I originally posted at bpo-15955, but am moving it to a separate issue so there is less confusion. GzipFile.read(<size>) etc is susceptible to decompression bombing. My patch tests and fixes that, making use of the existing “max_length” parameter in the “zlib” module.

The rest of bpo-15955 is about enhancing the bzip and LZMA modules to support limited decompression, but since the zlib module can already limit the decompressed data, I think this gzip patch should be considered as a bug fix rather than enhancement, e.g. the fix for bpo-16043 (gzip decoding for XML RPC module) assumed GzipFile.read(<size>) is limited.

Especially now that this is only going to go into 3.5, I think it makes more sense to handle GzipFile, LZMAFile and BZ2File all in one go. Looking at the code, otherwise there's going to be a lot of duplication.

How about introducing a base class 'CompressedFile' that defines most of the logic that's currently in LZMAFile (including the max_size patch from bpo-23529), and having {LZMA,BZ2,Gzip}File all inherit from that base?

BZ2File and LZMAFile would probably only need to define their own constructor to instantiate the proper compressor/decompressor object.

GzipFile would need to additionally overwrite read() and write() in order to handle the CRC and gzip header. But I think both methods could still be written to call super().read/write().

Did I miss something?

Perhaps we should move the discussion of a common base class to bpo-23529. I only opened this as a separate issue because I thought it might be appropriate as a bug fix for 3.4.