Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 20 Apr 2023 11:28:22 -0400
From: "David A. Wheeler" <>
Subject: Re: Perl's HTTP::Tiny has insecure TLS cert default,
 affecting and other modules

> |Steffen Nurpmeso <> 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 <> 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.