develooper Front page | perl.perl5.porters | Postings from December 2021

Re: OpenSSL alternative support WAS Re: Pre-RFC: support httpsout-of-the-box

Thread Previous | Thread Next
From:
Craig A. Berry
Date:
December 9, 2021 03:43
Subject:
Re: OpenSSL alternative support WAS Re: Pre-RFC: support httpsout-of-the-box
Message ID:
CA+vYcVzD7JJ18mY9EePB7UZ5xWcqtvSm8ASFDQBq+q6QnKSUNg@mail.gmail.com
On Wed, Dec 8, 2021 at 1:12 PM Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:
>
> Two other facts which seem relevant, that haven't been mentioned so far:
>
>   1) Perl is currently supported on many more platforms than OpenSSL is
>
>   2) OpenSSL requires perl during its build process
>
> For both of these reasons, core perl *cannot* require OpenSSL.

It cannot require it but it can provide Perl-level support for TLS if
the underlying capability is available.  This has all been covered in
the original thread Neil started.  Obviously it must still be possible
to build Perl without SSL support via Configure-time mechanisms that
exclude Net::SSLeay and IO::Socket::SSL (and Mozilla::CA) when the
underlying library support (LibreSSL or OpenSSL) is not available.  As
I've previously mentioned, that's more difficult than similar
Configure-time questions such as "does the GDBM library exist?" but I
don't think it's impossible.

If you can build a Perl without TLS support, then you can build
OpenSSL on any platform it supports, because OpenSSL does not require
an SSL-enabled Perl to build.  Pretty much any old Perl will do.  So
your #2 just goes away and has nothing to do with what core Perl can
or should do.

As far as your #1, platforms that do not support OpenSSL in the sense
of being able to build OpenSSL on the platform are few and far
between.  What platforms does Perl support that do not support
OpenSSL? If by "support" you mean installed by default, that's a
different matter.  Notably Windows and macOS do not have OpenSSL nor
LibreSSL present by default, so it cannot be relied on to be available
and the OS vendor does not supply a standard mechanism to get it.
There are other ways to get it, and people who build Perl installers
for those platforms may want to ensure that it's available.

As others have mentioned, CPAN.pm will use TLS support via curl or
wget if Perl module support is not available and those utilities have
the relevant capabilities.  That will be completely adequate in many
cases, such as some hypothetical Linux distro that has a curl enabled
with gnuTLS but no OpenSSL nor LibreSSL included.

I don't think it is possible near-term to guarantee that every Perl
installation has TLS 1.2+ support with certificate verification.  But
it seems feasible to greatly narrow the impact of the CVEs by ensuring
that support via Perl modules is available if the libraries upon which
those modules depend are available.

There are plenty of challenges and no perfect solutions, such as the
same chicken-and-egg problem everyone has of needing to update your
certificate store using a certificate that may have been revoked but
you won't know until after you've updated your certificate store.  But
is there any reason other than it's hard work that Perl shouldn't
include Net::SSLeay, IO::Socket::SSL, and Mozilla::CA in the core and
build them whenever the underlying support is available?

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About