curl / Mailing Lists / curl-library / Single Mail
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 ?

From: Timothe Litt <>
Date: Mon, 1 May 2023 15:59:24 -0400

On 01-May-23 15:18, Daniel Stenberg wrote:
>> * Rather than hiding in description, add key for "known exploits" -
>>   value can be boolean. [will this be updated if updates are
>>   discovered after publication?  If not, what's the value of having it?]
> We basically never get that information. I don't think we can maintain
> such info with dignity.

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.

>> * including a link to the CVE on (was
>> [text, and/or the GET API
>> <>to return the CVE record]
> The MITRE details for curl flaw are mostly useless and I instead much
> rather prefer people use and read *our* documentation for our flaws
> than any other resource.
Understood, but 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.  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.  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.

Timothe Litt
ACM Distinguished Engineer
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

Received on 2023-05-01