Front page | perl.perl5.porters |
Postings from June 2022
Re: Pre-RFC: support https out-of-the-box
Thread Previous
|
Thread Next
From:
Elvin Aslanov
Date:
June 14, 2022 16:18
Subject:
Re: Pre-RFC: support https out-of-the-box
Message ID:
CAJ4KP=2rSQdFLwEBK0oEpgai5BsBoG-GwtJmR090GOFuqvsQww@mail.gmail.com
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 <felipe@felipegasper.com>
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:
> https://stackoverflow.com/a/4141173/586723
>
> -FG
>
>
> > On Jun 13, 2022, at 19:56, Elvin Aslanov <rwp.primary@gmail.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 <neilb@neilb.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
>
>
>
Thread Previous
|
Thread Next