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: Daniel Stenberg via curl-library <>
Date: Mon, 1 May 2023 21:18:38 +0200 (CEST)

On Mon, 1 May 2023, Timothe Litt via curl-library wrote:

> Good start.  A few things to consider:

I decided to try to use something like

Lots of tiny changes have been applied.

> * 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.

> * Does each entry need a revision # (e.g. if the first fix is
> incomplete/incorrect)?

There is now a "modified" date stamp.

> * should reporter,patcher be arrays?

They are now a 'credits' array.

> * 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

> * If this is automated, how does the automation know when to include a
> CVE? When current release >= "last"?  Does this fit the final
> publication policy?

It is automated and it re-generates the list when there are updates to the
CVEs or additions. The website is generated with a set of makefiles.

Thanks for the feedback!

  | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features

Received on 2023-05-01