Front page | perl.perl5.porters |
Postings from June 2022
Re: Pre-RFC: support https out-of-the-box
From: Felipe Gasper
June 14, 2022 17:00
Re: Pre-RFC: support https out-of-the-box
Message ID: A710B764-2FA7-4F93-B4E8-DD79C1259FC7@felipegasper.com
If we’re OK with that then we could ship mbedTLS and have TLS always “just work”.
I’ve been under the impression that’s unacceptable to depend on users to update TLS stuff manually, be it the root store or the code.
> On Jun 14, 2022, at 12:18, Elvin Aslanov <email@example.com> wrote:
> yeah but `cpan Mozilla::CA` isn't hard to do to update the module and it won't break with newer Perl versions as well since it's just plaintext non-code certificates bundle
> On Tue, Jun 14, 2022 at 7:52 PM Felipe Gasper <firstname.lastname@example.org> wrote:
> 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 <email@example.com> 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 <firstname.lastname@example.org> yazdı:
> > I've tried to re-read all the different threads related to this,
> > but Spark mail gets confused, and reading this all via nntp.perl.org
> > 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 CPAN.pm 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