Re: PSC #166 2024-10-31

On Fri, Nov 1, 2024 at 2:34 AM Aristotle Pagaltzis via perl5-porters <
perl5-porters@perl.org> wrote:

> * We discussed with Leon and Tim what we want to do to have
>   TLS support in core. Future support for underlying APIs other
>   than OpenSSL is desirable. Net::SSLeay also has cruft that we
>   would prefer to avoid in core.
>
>
> https://blogs.perl.org/users/psc/2024/11/this-week-in-psc-166-2024-10-31.html


Essentially there are three ways to approach this

Solution 1: Put Net::SSLeay in core.

This is the most obvious solution. Primarily because the code of the module
already exists. There are some complications around building it. The first
is that it would have to be an optional dependency by necessity, given that
it won't be available in all places where perl should be (it's only common
on Linux and friends really). Even more complicating is OpenSSL not having
the kind of backward and forward compatibility that perl has. Compiling a
new Net::SSLeay with an old OpenSSL is supported well enough, but compiling
an old Net::SSLeay on a new system. Since you generally can't know the last
supported OpenSSL version ahead of time it's not necessarily possible to
cleanly detect if it can be supported or not. This is not an imaginary
problem and can easily be observed today when installing an older Ruby
version. Also Net::SSLeay has a lot of historical baggage and we may want
to fork it to remove that.

Pros: Little new code needs to be written, only Configure.
Cons: It can break with a future OpenSSL upgrade.


Solution 2: Write a wrapper around another TLS library that can be embedded
into core.

This will need an abstraction layer so IO::Socket::SSL (or a fork) can
choose between it and Net::SSleay.

Pros: No external dependencies, it (theoretically) works everywhere.
Cons: Needs a new wrapper to be written from scratch. Licensing makes the
list of potential libraries very small. We may need to fork IO::Socket::SSL
since it exposes parts of Net::SSLeay.


Solution 3: Write a wrapper that can use OS specific libraries (e.g. Apple
Secure Transport / Network Framework, Microsoft SChannel).

Like option 2 this will need an abstraction layer so IO::Socket::SSL (or a
fork) can choose between it and Net::SSleay. This option is probably good
when combined with solution 2.

Pros: likely the best option for that platform when it is supported
Cons: platform specific, needs a new wrapper to be written from scratch. We
may need to fork since IO::Socket::SSL exposes parts of Net::SSLeay.


In summary, all options have downsides but ideally we'd do all of them.

• PSC #166 2024-10-31 by Aristotle Pagaltzis via perl5-porters
• Re: PSC #166 2024-10-31 by Leon Timmermans
• Re: PSC #166 2024-10-31 by Leon Timmermans
• Re: PSC #166 2024-10-31 by Scott Baker
• Re: PSC #166 2024-10-31 by Alexander Hartmaier
• Re: PSC #166 2024-10-31 by Paul "LeoNerd" Evans
• Re: PSC #166 2024-10-31 by Paul "LeoNerd" Evans