Front page | perl.perl5.porters |
Postings from June 2022
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. > > NeilThread Previous | Thread Next