Front page | perl.perl5.porters |
Postings from December 2021
On Wed, Dec 8, 2021 at 10:12 PM Felipe Gasper <felipe@felipegasper.com> wrote: > > > On Dec 8, 2021, at 22:42, Craig A. Berry <craig.a.berry@gmail.com> wrote: > > > > 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? > > It occurs to me (as Iâve been learning mbedTLS) is that IO::Socket::SSL explicitly wraps Net::SSLeay/OpenSSL/LibreSSL. > > ISTM a more ideal pattern would be some library-agnostic mechanism that doesnât privilege one TLS library over another. Curl, for example, can use OpenSSL, GnuTLS, wolfSSL, NSS, mbedTLS, Secure Transport, or any of several others. > > I know of no such abstraction on CPAN now, in December 2021, but I thought it still worth mentioning. Broader support would be ideal, but hard to justify as in scope for Perl core development. The good news is that anyone interested is free to explore such support on CPAN, possibly via new modules or possibly via enhancements to existing ones. Can Net::SSLeay be taught about other TLS libraries? I don't know; I suspect the only reason LibreSSL works is that it's just a fork of OpenSSL with all the non-Linux support gleefully chopped out, but that doesn't mean it's impossible. Or maybe IO::Socket::SSL is the more appropriate place to plug in different lower-level modules that support different TLS libraries. Or maybe HTTP::Tiny could have support for Net::Curl shoehorned into it, but then it wouldn't be that tiny and would add libcurl as a dependency. There are numerous non-trivial development efforts that could broaden TLS support to different implementations. But if Perl core does anything near-term, I think it needs to focus on bundling what's already available. Just my $0.02.Thread Previous | Thread Next