develooper Front page | perl.perl5.porters | Postings from December 2021

Re: OpenSSL alternative support WAS Re: Pre-RFC: support httpsout-of-the-box

Thread Previous | Thread Next
From:
Oodler 577 via perl5-porters
Date:
December 2, 2021 05:13
Subject:
Re: OpenSSL alternative support WAS Re: Pre-RFC: support httpsout-of-the-box
Message ID:
YahVpqkaPaOfWAl9@odin.sdf-eu.org
* Felipe Gasper <felipe@felipegasper.com> [2021-12-01 23:52:23 -0500]:

> 
> > On Dec 1, 2021, at 22:16, Darren Duncan <darren@darrenduncan.net> wrote:
> > 
> > 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.
> 
> Toward this end: how feasible would it be to bundle something like mbedTLS--optionally?--with Perl in order to have out-of-the-box HTTPS?
> 
> -FG

This seems to be all tending towards the problem native package
managers solve. And in this case, supporting "other" SSL should
probably fall something that Net::SSLeay would then be able to
use. Far be it from me to damper the conversation, but I have to
point out that this is just shifting the "problem" around and
even creating new ones. Not that these ideas do not contain merit;
but the origin pre-RFC of "supporting https" out of the box is
predicated on the practical fact that OpenSSL support on each
platform is very specific to the maintainers of each platform.

And we should be weary of adopting the same problems of making
sure this works on all the platforms supported by perl - even if
there is some kind of check of if "openssl is installed". I've
had fairly recent experiences of Net::SSeay/IO::Socket::SSL falling
behind new Ubuntus, as I have mentioned.

I also don't see much difference between "checking for openssl",
keeping in mind you don't need the binary, you need the development
libraries/headers; and checking to see if for a base or available
perl, the package for Net::SSeay exists (and if so, install it).

This really only works if using a base perl or a perl formally
supported in the platform's native package manager. Which is not
always straightforward since FreeBSD supports the different perls;
and as I type this I can't say which one, say the p5-Net-SSeay
port wants. They tend to be pretty good about using whichever one
is the "designated" perl (on FreeBSD), so it may be a moot point.

FWIW, outside of Debian/Ubuntu, OpenBSD is the other "major" platform
shipping with a base perl. Then there's NetBSD's pkgsrc, which
does support a lot of platforms (and is used as the native package
manager for some of them). But I don't think we want to be including
our own pkgsrc based dependency manager thingy either. Maybe I am
over thinking this, hopefully I am.

Cheers,
Brett

-- 
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About