This report came from a free tool, trivy, I filed a Github discussion about it here: https://github.com/aquasecurity/trivy/discussions/6722
On Fri, May 17, 2024 at 12:08 PM Salvatore Bonaccorso <car...@debian.org> wrote: > Hi, > > On Fri, May 17, 2024 at 10:43:26AM -0400, John Waffle wrote: > > Package: zlib > > Version: 1:1.2.13.dfsg-1 > > > > Related bug reports: > > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054290 > > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056718 > > > > These were marked as resolved but it seems like I'm getting some > > contradictory information. > > > > - The zlib package page https://tracker.debian.org/pkg/zlib says that > > CVE-2023-45853 < > https://security-tracker.debian.org/tracker/CVE-2023-45853> > > is ignored, what is the basis for ignoring this CVE? > > - Is there a plan to backport zlib 1:1.3.dfsg-3.1 to bookworm? It looks > > like it's currently in trixie > > > > The maintainer of zlib said this in a comment > > https://github.com/madler/zlib/pull/843#issuecomment-2050417533 > > > > > Sigh. I tried. > > > > > It is this page: > > https://security-tracker.debian.org/tracker/CVE-2023-45853 , that > > incorrectly marks 1:1.2.13.dfsg-1 as vulnerable, when in fact it has no > > minizip code in it whatsoever. (I verified that by downloading it and > > listing the external symbols in the .so file.) I managed to reach someone > > at debian.org who seems to be in control of that page, but instead of > > fixing the page, they defended it, even though it's wrong. > > > > Can a Debian maintainer elaborate on this? Do the Debian maintainers feel > > like this version of zlib is vulnerable or not? > > > > If the Debian maintainers could confirm that this is not a real > > vulnerability, maybe then we can get trivy to stop flagging this as a > > critical vulnerability in their scan. This is a rather big problem > because > > a lot of images use Debian (bookworm specifically) and a lot of base > images > > (e.g. nginx) are getting flagged for this. > > Again, the notes explain the tracking; The zlib is *source* in the > security-tracker not the binary package produced. Thus the entry reads > as: > > - zlib 1:1.3.dfsg-2 (bug #1054290) > [bookworm] - zlib <ignored> (contrib/minizip not built and > producing binary packages) > [bullseye] - zlib <ignored> (contrib/minizip not built and > producing binary packages) > [buster] - zlib <ignored> (contrib/minizip not built and producing > binary packages) > > is there in the wording which you think needs improvement? > > Why does your security-scanner not consider the information gathered > by the security-tracker including the 'ignored' state there? Can you > bring that to your vendor of the security scanner? > > Regards, > Salvatore >
