Open washeck opened 1 month ago
This CVE was reported back in 2019 and popped up again in 2022, highly disputed and ignored (reasonable IMO) that time: https://github.com/advisories/GHSA-f6pv-j8mr-w6rr
I do not see a single other reference, that this has somehow worsened with latest jinja2 or that it has been newly found to be more problematic than rated (by the majority) that time. To me it looks like Safety just hit an update button, triggering this CVE to be recognised again, while nothing has changed: https://data.safetycli.com/v/70612/97c/
The very same applies to CVE-2018-20225
from 2018/2019: https://data.safetycli.com/v/70612/97c/
About a "vulnerability", which IMO is totally natural for any kind of package index system, so you could call APT from Debian/Ubuntu vulnerable as well. When adding "extra" indexes for additional packages, newer versions or binary vs source builds, this is naturally something the admin must take care of, there is no solution. And pip
even has the --index-url
option to enforce a particular index, compared to --extra-index-url
, which does and behaves exactly how it should, IMO.
Triggering such old, disputed and (reasonably IMO) ignored CVEs to make every safety
run fail does not make sense. Not sure what the purpose behind this is, probably to move free to paid plans. As free user, one does not see that there is no solution for any of the two CVEs, but that they have been intentionally ignored since years. EDIT: Sorry for the insinuations, it was probably not intentional and/or externally triggered.
EDIT: Okay, the update was probably triggered from other databases: https://nvd.nist.gov/vuln/detail/CVE-2019-8341#VulnChangeHistorySection, https://nvd.nist.gov/vuln/detail/CVE-2018-20225#VulnChangeHistorySection
The exact same happened there on exactly the same dates:
CVE Modified by MITRE 3/20/2024 10:34:17 PM
Action Type Old Value New Value Added Tag MITRE disputed
A disputed
tag was added in March, and then other updates without visual change until mid May. Probably safety
should recognise tags which indicate that it is disputed, and ignore old CVEs then. So yeah, fully agreeing with OP here.
EDIT2: Probably these are better reported here as false positives? https://github.com/pyupio/safety-db/issues EDIT3: Similar case with some comments from safety maintainer: https://github.com/pyupio/safety-db/issues/2363#issuecomment-1520462379 Makes sense that free users see this just now, due to 30 days delay.
Description
Safety includes a dependency to
jinja2
(which we otherwise don't need in our project) and because SafetyDB includes also disputed vulnerabilities, we are getting this error:It think it would be good if security scanner did not report its own dependencies as vulnerable without fix available. In general, I think you should not include the disputed vulnerabilities by default, because all of them I investigated are useless and it just forces me to add evergrowing list of excludes.