On Wed, 2025-01-29 at 19:50 +0000, Eduard Stefes via GNU gzip discussion and bug reports. wrote: > Hi, > > On Wed, 2025-01-29 at 10:58 -0800, Paul Eggert wrote: > > Thanks for the bug report. I installed the attached, a bit simpler > > than > > the patch you suggested; can you please give it a try? > changing the call fill_inbuff(1) to fill_inbuff(0) will not work. > dfltcc works on the outbuf, and fill_inbuff will eventually call > flush_window in case it hits EOF && 0. But it will NOT call > flush_outbuf() which we need in this case. > > > > > > > Also, is there a related bug near dfltcc.c line 375? That is, when > > (inptr == insize && fill_inbuf (1) == EOF && param->cf), won't > > insize > > then be zero, so that gzip will go into an infinite loop attempting > > to > > read past EOF? > I will think about this and try to come up with a test for it. To me > it > looks like inbuf is preallocated (gzip.c:135) so it might be ok to > read > past EOF and just compress zeros. The logic around it should prevent > access past inbuf[MAX]. But better be save then sorry.
So I thought about this and talked with Ilya. We think that the only possibility for a problem here, is if faulty hardware updates param->cf incorrect. > > In that matter, should I extract the failing gzip tests from rsyslog > and add them to the gzip test suit? question remains: should I extract the failing rsyslog test cases for gzip? This tests test if partially written or truncated gz files can be extracted as expected. I read rfc1952 and there is no explicit statement saying that incomplete gz files *are corrupt or invalid*. Point 2.3.1.2. of the rfc does not require the CRC32 and ISIZE field to be checked by a decompressor. And Point 4. recommends that systems using gz should *provide some means of validating the integrity of the compressed data*. This all lets me conclude that it is indeed ok and valid to have truncated gz files. And that it would be good to test this cases. > > -- > Eduard Stefes <eduard.ste...@ibm.com> -- Eduard Stefes <eduard.ste...@ibm.com>
