Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: all previous curl CVEs as JSON ?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 1 May 2023 23:37:30 +0200 (CEST)
On Mon, 1 May 2023, Timothe Litt wrote:
> Then perhaps the sentence "We are not aware of any exploit of this flaw."
> shouldn't appear in the descriptions, since it persists long after the
> initial publication.
Right, it's a challenge to provide information at the time of the disclosure
that we can't really monitor and keep track of over time after it is first
published. But that line is still factually true. We are rarely informed about
curl exploits, but then again we don't try to figure out if there are any.
So yeah. Does the line help or does it mislead? I don't know.
> Understood, but www.cve.org is where the CVE numbers are assigned and is the
> first stop for the curious. And it feeds the NVD. So it will be viewed as
> "official" by most.
Yes, which is exactly why I repeatedly and as often as I can point out to
people that for curl issues: READ THE CURL DOCS because MITRE and NVD are
inflating the scores (on purpose) and show a very incomplete picture of flaws.
Official yes; good no.
> I'm not sure how it's currently run - they're in transition. But you may
> want to investigate becoming an "open source partner", which it appears
> would enable you to update the CVE records for curl so that they're
> accurate.
It's not that easy. I'm in communication with them because of their nasty
habit of inflating our vulnerability severities but they think they help the
community this way and it's not like they care much what I think about it.
It has been proposed that *maybe* by being a CNA we could manage this better,
but that's also a lot of extra complexity and work.
> Whatever the mechanism, it would be better to try to correct the system of
> record than to let it run open loop and hope people will go the the project
> for information.
You would think so. Welcome to my world. I've been having this fight for a
while already, and I can't say that I have received a lot of sympathy for my
views in my talks with NVD.
Until they change, I will insist on directing people to curl.se for
information about past curl vulnerabilities. Because other sources are likely
to not tell the same truths.
Date: Mon, 1 May 2023 23:37:30 +0200 (CEST)
On Mon, 1 May 2023, Timothe Litt wrote:
> Then perhaps the sentence "We are not aware of any exploit of this flaw."
> shouldn't appear in the descriptions, since it persists long after the
> initial publication.
Right, it's a challenge to provide information at the time of the disclosure
that we can't really monitor and keep track of over time after it is first
published. But that line is still factually true. We are rarely informed about
curl exploits, but then again we don't try to figure out if there are any.
So yeah. Does the line help or does it mislead? I don't know.
> Understood, but www.cve.org is where the CVE numbers are assigned and is the
> first stop for the curious. And it feeds the NVD. So it will be viewed as
> "official" by most.
Yes, which is exactly why I repeatedly and as often as I can point out to
people that for curl issues: READ THE CURL DOCS because MITRE and NVD are
inflating the scores (on purpose) and show a very incomplete picture of flaws.
Official yes; good no.
> I'm not sure how it's currently run - they're in transition. But you may
> want to investigate becoming an "open source partner", which it appears
> would enable you to update the CVE records for curl so that they're
> accurate.
It's not that easy. I'm in communication with them because of their nasty
habit of inflating our vulnerability severities but they think they help the
community this way and it's not like they care much what I think about it.
It has been proposed that *maybe* by being a CNA we could manage this better,
but that's also a lot of extra complexity and work.
> Whatever the mechanism, it would be better to try to correct the system of
> record than to let it run open loop and hope people will go the the project
> for information.
You would think so. Welcome to my world. I've been having this fight for a
while already, and I can't say that I have received a lot of sympathy for my
views in my talks with NVD.
Until they change, I will insist on directing people to curl.se for
information about past curl vulnerabilities. Because other sources are likely
to not tell the same truths.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-05-01