"vulnerable" should not be green

[jonasstein]

green should be used for good/safe situations.

https://repology.org/projects/?maintainer=desktop-misc%40gentoo.org&inrepo=gentoo&problematic=1

vulnerable▲ - version is potentially vulnerable as there are related CVEs.

I suggest white on red.

[AMDmi3]

I take it as you've misunderstood the legend. Vulnerable status is denoted by the yellow warning sign, not the background color. The color indicates version status (up to date/outdated).

[KOLANICH]

Vulnerable status is denoted by the yellow warning sign

Why not a scull and bones emoji?

[jonasstein]

@AMDmi3 OK, I understand. However the impression is misleading, because the green dominates and the yellow triangle is so tiny. I still suggest to change it to a more significant symbol like a large UTF8 ⚠, or

instead of

(sorry for the delay)

[AMDmi3]

This looks reasonable.

[FedericoCeratto]

The background color is the most visually striking element. It can appear alarming on badges. I suggest using a red background exclusively for vulnerable packages and not for "outdated" versions.

[AMDmi3]

I suggest using a red background exclusively for vulnerable packages and not for "outdated" versions.

Definitely no. Vulnerabilities are not the main topic of Repology, and also NVD quality and coverage is lacking, making it not suitable for primary package classification. However, vulnerabilities correlate pretty well with software freshness, and in most cases when new CVE is published, (only) the latest software version is not susceptible to it. So even for this purpose, it's still sensible to rely solely on freshness, and that also works for all cases not covered by NVD, such as not (yet) known vulnerabilities, not published vulnerabilities, vulnerabilities not yet analyzed and properly filled in NVD, CVES not matched with projects and CVES with incorrect versions not suitable for matching.

[FedericoCeratto]

vulnerabilities correlate pretty well with software freshness

This is not true in general. Security-oriented distributions develop and distribute security updates for stable and LTS releases of the distribution. Over time, if more vulnerabilities are discovered, published and fixed the level of security of "legacy" software improves. On the other hand, feature releases from upstream might provide security fixes but also contain newly created vulnerabilities. (At risk of stating the obvious: vulnerabilities can be discovered at any time but can only be created by new releases)

[AMDmi3]

It's a mere speculation and opposite arguments of the same level of groundlessness may be given.

There are clear problematic scenarios with what you call "security-oriented distributions" approach:

• When a CVE is published, in most cases there's already an upstream release which has it fixed. Distributions which keep up to date with upstream are thus safe, while "security-oriented distributions" are exposed to vulnerability from the moment it's published until they patch it, if they patch it.
• When a vulnerability is silently fixed upstream, users of latest release are again safe, while "security-oriented distributions" may not get the fix at all.
• All the hypothetical newly introduced vulnerabilities will eventually get to "security-oriented distributions" as they don't stay on ancient versions forever.

On the other side of the scale is the assumption that security is improved if the new code is withheld from users for [some] period to allow freshly introduced vulnerabilities to be fixed. The truthfulness of that hypothesis depends on actual vulnerability longevity, frequency, time to discover, time to publish, percentage of published vulnerabilities, time to fix in the distro, coverage of patched vulnerabilities and many other factors, and dynamics thereof over time and project maturity. Unfortunately I haven't seen any comprehensive studies on this subject, and without these I cannot consider the named approach sensible. To be fair, the term "security-oriented distribution" is not even correct here. You are speaking of "stable distribution", with primary goal not directly related to security (but of course it has to keep it's "stable" package base patched), and not necessarily at all being "more secure" as the result.