develooper Front page | perl.perl5.porters | Postings from June 2022

Re: Pre-RFC: support https out-of-the-box

Thread Previous | Thread Next
Felipe Gasper
June 14, 2022 15:52
Re: Pre-RFC: support https out-of-the-box
Message ID:
Dual-life of Mozilla::CA seems problematic for the same reason as bundling a TLS library: the need for updates.

Most OpenSSL installs seem to include a root bundle; could we defer to that instead?

A short C snippet that shows how to get that directory:


> On Jun 13, 2022, at 19:56, Elvin Aslanov <> wrote:
> Awesome, totally agree on the first approach.
> I hope to see these three distributions in core for  Perl 5.38.
> These three modules are already heavily used on almost all Perl applications as de-facto SSL standard, so why not dual-life them finally?
> Usually installing the IO-Socket-SSL package pulls the two others as dependencies on Unix systems used for HTTPS support in Perl.
> Curl is PHP's approach to HTTP(S) from the beginning. It's already too late to consider Curl as an option I believe. Because it's an alien in the Perl world, and not as mature and integrated as the previous three.
> These are my thoughts stemming from my personal experience with Perl on Unix for many years.
> Thanks.
> 14 iyn 2022, Ç.a. 01:11 tarixində Neil Bowers <> yazdı:
> I've tried to re-read all the different threads related to this,
> but Spark mail gets confused, and reading this all via
> ain't user friendly either.
> The motives are, at least, the following:
>  - almost all APIs are https these days
>  - and increasingly all websites
>  - it will enable to do https on a fresh install
>  (it has other options for https, but those might not be available)
> options:
>  1. bundle modules, look for openssl (and poss other libs)
>  2. bundle an SSL lib and modules such as Mbed TLS, WolfSSL
>  3. Go with Curl, as it can work with a range of SSL libraries
>  4. work with various SSL programs (wget, curl, etc)
>  5. anything else?
> I suspect that the path of least resistance right now is to take
> the first option:
>  - dual-life Net::SSLeay, IO::Socket::SSL, and Mozilla::CA
>  - Configure would look for OpenSSL or LibreSSL
>  - presumably it would have to make sure it's a recent enough version
>  - possibly refuse to proceed with certain versions that are now
>  known to have serious security issues
>  - cope with a later version of OpenSSL that's incompatible
> We'd have to approach the current maintainers of those modules to
> see if they're happy for them to be bundle, explaining the implications.
> Net-SSLeay's Makefile.PL has stuff to to look for OpenSSL and work
> out compatibility. One possible path is that someone familiar with
> that stuff works with someone familiar with metaconfig, so that
> when installed with Perl, Configure is doing the heavy lifting,
> but it can still be installed from CPAN with Makefile.PL doing its thing.
> This doesn't preclude people starting parallel efforts to experiment
> with other approaches, but my sense is that more effort has been put
> into Net::SSLeay + OpenSSL, so we should start off on those shoulders.
> There are a number of pieces to this pie, so I'm guessing this will
> probably need a small group of people to work on it.
> I wonder if a good first step would be a proof-of-concept:
> a. hack together a metaconfig unit based on Net::SSLeay's Makefile.PL
> b. if Net::SSLeay builds and tests successfully, then install
>     Net::SSLeay, IO::Socket::SSL, and Mozilla::CA
> c. Contact the maintainers of those modules to sound them out on
>     openness to dual-lifing.
> d. See if this can be made to work on Linux, *BSD, MacOS, and Windows.
> Going with Curl is appealing, but unless we've got someone prepared
> to take that on, it feels more complex and less well-known than the
> approach outlined above.
> Neil

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About