-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"vulnerable" should not be green #156
Comments
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). |
Why not a scull and bones emoji? |
@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) |
This looks reasonable. |
The background color is the most visually striking element. It can appear alarming on badges. |
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. |
This is not true in general. Security-oriented distributions develop and distribute security updates for stable and LTS releases of the distribution. |
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:
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. |
green should be used for good/safe situations.
https://repology.org/projects/?maintainer=desktop-misc%40gentoo.org&inrepo=gentoo&problematic=1
![2020-11-12_screenshot_0c8fda3e](https://user-images.githubusercontent.com/298682/98991180-ca225080-252b-11eb-8e9d-a381f9dfb0df.png)
vulnerable▲ - version is potentially vulnerable as there are related CVEs.
I suggest white on red.
The text was updated successfully, but these errors were encountered: