- Issue created by @O'Briat
I can't reproduce the
composer audit
finding on branch 10.0.x by typingcomposer install && composer audit
. And those Symfony library pins released in 10.0.3. I don't see how that one is valid. I think that section should be removed from the issue summary so as not to confuse everyone.I am glad someone is testing out the OWASP tool because I had been meaning to look at it. Thank you for using Docker so others can reproduce the results.
Is there a way to run the tool in a more verbose mode so we can understand how the software determines these very old issues exist?
Are you definitely sure that the tool is listing these as issues, or as any CVE ever to affect that project?- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
I'm not sure why this is filed against Drupal core? Shouldn't it be against the OWASP tool instead?
- Status changed to Postponed: needs info
almost 2 years ago 11:58pm 6 February 2023 - π«π·France O'Briat Nantes
@cilefen: This core issue should reproduce with a drupal/core 9.4.10, I'll try to send a simple compose.lock that could be used to reproduce the issue.
@larowlan I add a comment on this issue: https://github.com/jeremylong/DependencyCheck/issues/1387
This current Drupal issue should be left open at least to track the problem (SEO) and I think some problem are unique to the Drupal way of version numbering: first locking major to core version as major, then free it again.
Maybe this wrong version matching could only be fixed by using specific options ? - Status changed to Needs work
almost 2 years ago 11:01am 7 February 2023 - Status changed to Postponed: needs info
almost 2 years ago 12:20pm 7 February 2023 Drupal 9.4.11 exists. I donβt understand the purpose of this issue.
- π«π·France O'Briat Nantes
This point is NOT a security issue, it's about why depency-check returns false positive or miss vulnerabilities.
Some problems come from the tool itself but other are Drupal dependant (version numbering at least).The goal is either to fix the Drupal side issues or to help depency-check to be more reliable since OWASP is the de-facto security standard.
My example above is just here to help to reproduce the problem.
Ah, understood. So in #7 you mean that there is in fact a library with a security bug in
symfony/http-kernel
thatcomposer audit
detects, and yet the OWASP tool does not detectsymfony/http-kernel
, and the OWASP tool detects different things which are false.- π«π·France O'Briat Nantes
Yes, that what I mean(it could be due to my bad english :))
Once again this issue is mainly "for the record" and to keep track of the "OWASP" problem.
On the Drupal side, the first task IMHO will be to discover why this tool (or the CVE database) mixes packages names. How an issue opened on View 6.x-2.2 14 years ago (https://nvd.nist.gov/vuln/detail/CVE-2008-6020) is matched with leaflet_views:2.2.12?
Maybe someone here could help the depency-check team to improve it ? Check the ComposerLockAnalyzer class:
https://github.com/jeremylong/DependencyCheck/blob/main/core/src/main/ja...