[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <A35F9CEA-C1F9-4D2B-8771-ED4EBA113B17@dwheeler.com>
Date: Thu, 20 Apr 2023 11:28:22 -0400
From: "David A. Wheeler" <dwheeler@...eeler.com>
To: oss-security@...ts.openwall.com
Subject: Re: Perl's HTTP::Tiny has insecure TLS cert default,
affecting CPAN.pm and other modules
> |Steffen Nurpmeso <steffen@...oden.eu> wrote:
> |> IMO it is no vulnerability at all since it has "always" been _very
> |> clearly_ (even very lengthily) documented in the manual page.
> Hanno Böck replied:
> |A vulnerability does not go away if it's documented, and I find that a
> |rather strange take.
> On Apr 20, 2023, at 8:56 AM, Steffen Nurpmeso <steffen@...oden.eu> wrote:
> Hm no, i do not, the latter not at all. You can bundle a OpenPGP
> / signify / even OpenSSL signature with something and can get
> secure download even over non-encrypted channels.
That's true, but irrelevant. The problem is that this function fails to
perform the security function implied by its name. If
HTTP::Tiny supports TLS (instead of rejecting it), it needs to verify TLS certs by default.
If there's function named "isodd()" where "isodd(4) === true", that's a bug,
even if the documentation said that's what it did. The function/method name
implies functionality. You could call it a naming bug. Papering over bugs helps no one.
The *default* of an externally-called function needs to be secure.
I'm sympathetic to the problem of loading in the *right* certs, but systems generally
already have mechanisms for configuring certs. That seems like a solved problem.
--- David A. Wheeler
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.
