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
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.

Thanks,

- J

Please direct any questions about security updates to the security team.

Please direct any questions about security updates to the security team.

Hi Mark,

How do I get in contact with them, should I just send a message to
security@debian.org?

Thanks,
- J

Hi Mark,

How do I get in contact with them, should I just send a message to
security@debian.org?

Thanks,
- J

Yes.

Yes.

Hi,

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

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 <carnil@debian.org> wrote:

Hi John,

So to add some additional datapoint: The issue araises here by maybe
thinking zlib refers to the binary package produced. It is correct,
for the binary package zlib then indeed you would not be vulnerable.

Let me as well elaborate on the "ingored". This comes as the binary
packages built from the *vulnerable* source, there is no point to
force an update in bookworm and older.

I hope this all get a better picture now on the CVE. If you still have
questions feel free to ask.

Regards,
Salvatore

Hello,

I got a response from trivy,
https://github.com/aquasecurity/trivy/discussions/6722#discussioncomment-9518531
.
packages)
------------------------------
<https://aquasecurity.github.io/trivy/v0.51/docs/supply-chain/vex/>.

I'll call out these particular points,

It sounds like this is some kind of incompatibility between how trivy
conceptualizes CVEs vs how Debian conceptualizes CVEs, plus a terminology
problem on the meaning of "ignored" (won't fix vs is not affected)

- Would you consider marking the vulnerability as "not_affected" instead of
"ignored"? Or does the Debian CVE tracking system not support that?

- I would agree that " [bookworm] - zlib (contrib/minizip not built and
producing binary packages)" doesn't have a standard format, but is there no
other viable way for a scanner to pick up on the CVE being ignored?

- Do you have docs to show what method should be used to properly handle
this issue being marked as "ignored"? Do you have any sample code / script
snippets you can share with me? Maybe I can submit a PR?

Maybe there is some way for trivy to notice that the issue is "ignored" and
then, for only Debian, interpret that as not_affected.

- John

On Sat, May 18, 2024 at 5:03 AM Salvatore Bonaccorso <carnil@debian.org> wrote:

Hello,

I was thinking about this a bit more and I had a question,
packages built from the *vulnerable* source, there is no point to force an
update in bookworm and older.

It sounds like Debian uses the "ignored" state to mean "this bug does not
affect the Debian package".

Is there another state that's used to indicate "won't fix"? Can we assume
that "ignored" always means "won't fix"? Or can "ignored" mean either thing
and we'd have to look in the notes to know for sure?

Thanks,
- J

Hi John,

Thanks for the query.
https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory
explains how <ignored> is to be interpreted when encountered. I think
security-scanner encountering it can classify it accordingly so that
no flag is raised.

Hope that helps,

Regards,
Salvatore