Your message dated Sat, 15 Jul 2023 23:27:41 -0300
with message-id <[email protected]>
and subject line pngcheck: check with zlib strict inflate
has caused the Debian Bug report #911657,
regarding pngcheck: check with zlib strict inflate
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
911657: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911657
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: pngcheck
Version: 2.3.0-7
Severity: wishlist
File: /usr/bin/pngcheck
pngcheck does not detect some cases of bad "window bits" size in the png
file. For example,
https://www.gutenberg.org/files/16713/16713-h/images/q169b2.png
(attached below, in case rectified soon)
pnginfo -d q169b2.png
=> libpng error: IDAT: invalid distance too far back
pngcheck q169b2.png
=> succeeds
whereas I hoped pngcheck would fail.
This is the IDAT "window bits" CINFO too small for what the data
actually needs. pngcheck inflates into a big output buffer and zlib by
default makes use of that, thereby tolerating the problem.
It'd be good if pngcheck used a copy of zlib compiled with its
INFLATE_STRICT option, so as to detect the problem.
Dunno if configury for a suitable copy of zlib would be easy or hard.
I tried a byte-by-byte wrapper which gets the same effect with normal
zlib, but is much less efficient of course.
--- pngcheck.c.orig 2007-07-08 16:23:31.000000000 +1000
+++ pngcheck.c 2018-10-23 17:36:13.000000000 +1100
@@ -1011,6 +1011,26 @@
}
+/* strict_inflate() same as inflate() but enforcing window size in the
+ manner of zlib compiled with its INFLATE_STRICT option. Normally
+ inflate() tolerates window size too small if the output buffer is big
+ enough that it contains the needed data. Going byte by byte here ensures
+ the output buffer isn't and thus window size too small is detected.
+ ENHANCE-ME: Better to use the zlib INFLATE_STRICT option.
+ */
+int strict_inflate(z_stream *z, int flush)
+{
+ /* "extra" is the part of avail_out not presented to inflate() */
+ int err;
+ do {
+ uInt extra = (z->avail_out ? z->avail_out - 1 : 0);
+ z->avail_out -= extra;
+ err = inflate(z, flush);
+ z->avail_out += extra;
+ } while (err == Z_OK && z->avail_in > 0 && z->avail_out > 0);
+ return err;
+}
+
int pngcheck(FILE *fp, char *fname, int searching, FILE *fpOut)
{
@@ -1807,7 +1827,7 @@
while (err != Z_STREAM_END && zstrm.avail_in > 0) {
/* know zstrm.avail_out > 0: get some image/filter data */
- err = inflate(&zstrm, Z_SYNC_FLUSH);
+ err = strict_inflate(&zstrm, Z_SYNC_FLUSH);
if (err != Z_OK && err != Z_STREAM_END) {
printf("%s zlib: inflate error = %d (%s)\n",
verbose > 1? "\n " : (verbose == 1? " ":fname), err,
--- End Message ---
--- Begin Message ---
First of all, thanks for taking your time filling this bug report and
sending the attached patch.
On my system, I was able to test and get the same output as you did
using the sample PNG file. But the root of the problem isn't zlib, as
both executables are linked against the same zlib version on my system.
The main difference is that pnginfo links against (and makes use of)
libpng, whereas pngcheck doesn't. This can be seen from the error you
got from pnginfo ("libpng error: IDAT: invalid distance too far back").
About using zlib compiled with INFLATE_STRICT, within Debian pngcheck
will use zlib as packaged in the archive. As such, it uses zlib with
whichever options it was compiled with. We could ask zlib maintainers to
compile it with INFLATE_STRICT support, but it could negatively affect
the other packages that depend on the current behavior.
As pngcheck development is basically in maintenance mode, with a lot of
security vulnerabilities found in the last couple years, I believe
diverging from upstream is not a good idea, thus I will not apply your
patch because of that, as upstream is unlikely to merge it on the
codebase or implement equivalent support.
Regards,
-- David
--- End Message ---
