Front page | perl.perl5.porters |
Postings from December 2021
* 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 #nativeThread Previous | Thread Next