On 2021-12-01 5:54 p.m., Ricardo Signes wrote: > On Wed, Dec 1, 2021, at 8:08 PM, Yuki Kimoto wrote: >> Suppose the Perl core contains Net::SSLeay. >> >> In this case, Net::SSLeay is already installed without the OpenSSL library and >> the tests of Net::SSLeay are not yet done. >> >> How do we test for correctness of behavior of Net::SSLeay? > > We would only build, test, and install Net::SSLeay if openssl was available. There is another important thing to consider in this discussion, which is the ability for core to use alternatives to OpenSSL. I have understood for years now that OpenSSL, unless I'm confusing it with something else, while widely used, also has serious quality issues. There are alternatives to OpenSSL which ostensibly are much better in quality control and are a fair bit tighter in focus and so are much less likely to suffer from enabling major security issues like HeartBleed and such. Historically installing modules to use SSL from CPAN meant users had a choice between OpenSSL and others. When adding SSL support to core, we should be doing it in such a way that better alternatives to OpenSSL can be used from core without OpenSSL or plain HTTP ever being needed to bootstrap that usage, as far as Perl is concerned. So the same logic for Perl core which tests the system and uses OpenSSL conditionally, it should also test the system for OpenSSL alternatives, and use them preferentially when we know they are better, or make it easy for the user to decide which to use. I am speaking primarily about what gets built-in at the start which is used when bootstrapping the toolchain, to enable downloading anything else from CPAN etc. -- Darren DuncanThread Previous | Thread Next