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 DuncanThread Previous | Thread Next