"unimportant" issues don't have security impact, but currently they get shown
as "vulnerable" in red, both in a package overview page, e.g.
https://security-tracker.debian.org/tracker/source-package/c-ares and CVE-specific pages, e.g.
https://security-tracker.debian.org/tracker/CVE-2023-31147

This is a little misleading, since those packages are not actually vulnerable.
It would be nice if such "unimportant" issues it would instead display
"unfixed (no/negligible security impact)" instead. And instead of red maybe
in grey.

Cheers,
        Moritz

Hi,

Right agree with that. I think it would be great and helpfull if we
have an issue which is unfixed in a particular suite source wise, and
in the above example, but is in unimportant severity, then instead of
a red vulnerable, the page would show a "greyed" (similar to fixed,
but different), with a different text something like you proposed in
wording.

I think the color difference from red is visual wise quite important,
because together with the wording 'vulnerable' is possibly what is
what people will mostly find surprising.

So whoever wants to implement that, plese make a MR accordingly to the
security-tracker repository.

Regards,
Salvatore

Be careful with trying to classify as important (security related) and
unimportant (not security related). It depends on proper
classification, and that does not always happen. Folks missed the
unimportant TTY1 layer bug for years until it became a CVE. CF.,
https://thenewstack.io/design-system-can-update-greg-kroah-hartman-linux-security/
.

I've also seen CVE-worthy bugs go without a CVE because someone could
not get the form on mitre.org to submit. At release time the Changelog
just said, "fixed bug XXX. This probably should have gotten a CVE."

And finally, many developers just fix important bugs without giving
them much thought. Fix it, check-in, move onto the next bug. No time
to analyze impact. In the past, I've cleared some memory problems and
wondered if someone could exploit them.

Grey or orange might make a good choice to differentiate them from
important or security updates. Grey almost feels like "disabled" and
you won't be acting on it. Maybe orange would be the better choice.

Jeff

Be careful with trying to classify as important (security related) and
unimportant (not security related). It depends on proper
classification, and that does not always happen. Folks missed the
unimportant TTY1 layer bug for years until it became a CVE. CF.,
https://thenewstack.io/design-system-can-update-greg-kroah-hartman-linux-security/
.

I've also seen CVE-worthy bugs go without a CVE because someone could
not get the form on mitre.org to submit. At release time the Changelog
just said, "fixed bug XXX. This probably should have gotten a CVE."

And finally, many developers just fix important bugs without giving
them much thought. Fix it, check-in, move onto the next bug. No time
to analyze impact. In the past, I've cleared some memory problems and
wondered if someone could exploit them.

Grey or orange might make a good choice to differentiate them from
important or security updates. Grey almost feels like "disabled" and
you won't be acting on it. Maybe orange would be the better choice.

Jeff