Front page | perl.perl5.porters |
Postings from December 2021
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