6 ms·

Can you explain how a CVE "awaiting analysis" forced you to "resolve" it? Just wondering how this works. I looked at the first one (https://nvd.nist.gov/vuln/d

by hoten 2y ago

Can you explain how a CVE "awaiting analysis" forced you to "resolve" it? Just wondering how this works. I looked at the first one (https://nvd.nist.gov/vuln/detail/CVE-2024-25355 https://nvd.nist.gov/vuln/detail/CVE-2024-25355) and obviously they time way too much of the "vulnerability", attributing their own test setup to your library (as you mentioned). So- someone reports a CVE (can just anyone do that?), and without any validation, some other services dings your library and now random users ask you "can you please fix your library"?

mmastrac 2y ago
That wasn't the library I had an issue with but the general problem is this: Downstream consumers of a library that have integrated Dependabot get alerts for CVEs filed against a library, even if the are "awaiting analysis". Those consumers send messages asking for a resolution, and there's no trivial way to push back that an advisory is false. For example, here's the one I'm griping about. This is marked as _Github reviewed_: https://github.com/advisories/GHSA-fqhp-rhm6-8rrj https://github.com/advisories/GHSA-fqhp-rhm6-8rrj I used the reporter's reproduction and could not reproduce the slowdown at all. It turns out that the testcase was slow only because they were printing the URL under test. https://github.com/progscrape/urlnorm/issues/1 https://github.com/progscrape/urlnorm/issues/1 As a maintainer, I have a choice: either I need to go and clean up all of the automated tools that respond to CVE spam, OR I just release a new version of a library, fuck it all and move on with my life after blocking the reporter. For what it's worth, Github did not respond to reports about this user, so I got to the point where I think everything is broken and I no longer care about anything other than clearing those alerts out.

6 ms·

Can you explain how a CVE "awaiting analysis" forced you to "resolve" it? Just wondering how this works. I looked at the first one (https://nvd.nist.gov/vuln/d

by hoten 2y ago

mmastrac 2y ago
That wasn't the library I had an issue with but the general problem is this: Downstream consumers of a library that have integrated Dependabot get alerts for CVEs filed against a library, even if the are "awaiting analysis". Those consumers send messages asking for a resolution, and there's no trivial way to push back that an advisory is false. For example, here's the one I'm griping about. This is marked as _Github reviewed_: https://github.com/advisories/GHSA-fqhp-rhm6-8rrj https://github.com/advisories/GHSA-fqhp-rhm6-8rrj I used the reporter's reproduction and could not reproduce the slowdown at all. It turns out that the testcase was slow only because they were printing the URL under test. https://github.com/progscrape/urlnorm/issues/1 https://github.com/progscrape/urlnorm/issues/1 As a maintainer, I have a choice: either I need to go and clean up all of the automated tools that respond to CVE spam, OR I just release a new version of a library, fuck it all and move on with my life after blocking the reporter. For what it's worth, Github did not respond to reports about this user, so I got to the point where I think everything is broken and I no longer care about anything other than clearing those alerts out.