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: Timothe Litt <litt_at_acm.org>
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 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.
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. 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
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 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.
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. 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.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature