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 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 https://ossf.github.io/osv-schema/
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 https://www.cve.org (was
> cve.mitre.org) [text, and/or the GET API
> <https://cveawg.mitre.org/api-docs/>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.
> * 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!
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 https://ossf.github.io/osv-schema/
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 https://www.cve.org (was
> cve.mitre.org) [text, and/or the GET API
> <https://cveawg.mitre.org/api-docs/>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.
> * 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!
-- / 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