Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 3 May 2023 15:57:59 -0400
From: Reid Sutherland <>
To:, "David A. Wheeler"
Subject: Re: Perl's HTTP::Tiny has insecure TLS cert default,
 affecting and other modules

On 5/3/23 15:54, David A. Wheeler wrote:
>> On May 3, 2023, at 3:15 PM, Reid Sutherland <> wrote:
>> Who actually decides when something receives a CVE?
> There's a process for assigning CVEs. Anyone who wants to be able to assign CVEs - that is, to become a CVE Numbering Authority (CNA) - has to follow various processes. I'm sure it can be improved, like all things. I'm not directly involved in this. You might find more information here:
>>   This can be used to defame projects and products as in this case.
> Identifying a vulnerability does not defame a project. If a library has the functionality to retrieve an https URLs, and fails to verify the server certificates by default, then I (and many others) would call that a vulnerability. After all, the default is what happens. If you request data from <>, you wouldn't expect it to use the data from <>. There's a general expectation that https://FPP provides a secure connection to FOO (with confidentiality, integrity, and server authentication), unless you specially disable it.
> --- David A. Wheeler

A default is not a vulnerability.  There are reasons why defaults cannot 
be changed in libraries once they are stable.  This is also why 
documentation exists.

Revoke these CVEs, it's a stain on the process.

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.