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 Duncan
> 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 Duncan