develooper Front page | perl.perl5.porters | Postings from June 2022

Re: Pre-RFC: support https out-of-the-box

Thread Previous | Thread Next
From:
Darren Duncan
Date:
June 16, 2022 14:58
Subject:
Re: Pre-RFC: support https out-of-the-box
Message ID:
dcb98ae2-4e97-0710-1954-daadfa4da50f@darrenduncan.net
THIS IS A DUPLICATE RESPONSE.  I HAD PREVIOUSLY SENT THE SAME THING UNDER AN 
ALTERED SUBJECT LINE.  REPEATED TO KEEP IT TOGETHER WITH THE MAIN THREAD.


I propose an alternate solution, summarized as bootstrapping.

Perl bundles an implementation of HTTPS support including certs or whatever, so 
there is zero dependency on any HTTPS library or files being with the operating 
system.

This bundled implementation is purposefully limited to only being able to invoke 
CPAN or similar, that is, it has an inclusion list which is limited to CPAN 
only, though users can add more to the inclusion list as a configuration if they 
have to, and connections to anything not on the list is refused.

All CPAN clients bundled with Perl are set to use this bundled HTTPS support 
instead of using HTTP.

Anyone wanting to use HTTPS in Perl for any purpose other than getting stuff 
from CPAN has to download a regular traditional HTTPS support module from CPAN, 
and then they would use that as they always have.  These can then rely on the 
system-provided HTTPS support and certs or whatever as they always have.

Given that the only thing the bundled HTTPS support has to do is talk to CPAN, 
it can be a lot more minimalist than a typical HTTPS support, not needing extra 
features than those cooperatively decided with the CPAN mirrors, and having no 
dependencies besides Perl itself.

This bootstrapping would also prevent circular dependencies in the case of any 
traditional HTTPS tools using Perl to build or install themselves.

I'm not advocating any specific HTTPS implementation to bundle a copy of, and 
I'm not suggesting building a new one from scratch (bad idea for security 
things), but we can pick some existing good implementation and strip it down 
either physically or by way of configuration, and keep the clone in some other 
namespace somehow so that its presence doesn't interfere with installing or 
using the regular version of the same tool.

So do others agree or not that this is better?

-- Darren Duncan


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