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

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

Thread Previous | Thread Next
Martijn Lievaart
December 12, 2021 10:16
Re: OpenSSL alternative support WAS Re: Pre-RFC: supporthttpsout-of-the-box
Message ID:
Op 12-12-2021 om 04:35 schreef Oodler 577:
> * Craig A. Berry <> [2021-12-10 16:22:27 -0600]:
>> On Fri, Dec 10, 2021 at 3:59 PM Martijn Lievaart <> wrote:
>>> Op 10-12-2021 om 22:30 schreef Craig A. Berry:
>>> [1]
>>>  From that page:
>>> Note  WinINet does not support server implementations. In addition, it should not be used from a service. For server implementations or services use Microsoft Windows HTTP Services (WinHTTP).
>>> If that means Windows Server implementations do not support this API, then another one should probably be used. But surely there is one that works on all types of Windows OS?
>> Thanks, but I think that just means you can't implement services with
>> it.  We don't want to implement an http(s) service, just an http(s)
>> client, even if it's running on a server version of Windows.
> I see this thread is still dragging on. Was the idea of
> documenting how to get it going on the most common systems
> using their native package systems dismissed conclusively
> dismissed as an idea? Beyond that, the only one that made
> any sense to me was, "try to install Net::SSLeay, but if
> it fails clean up the mess and move on".

I don't think there was a conslusion, although I think the consensus 
emerged that (give or take a few nuances):

* The context is still safely installing packages from CPAN, not 
providing SSL in general. If we can also do that, great, but it's not 
the goal here.

* Having SSL in core does not seem possible in all situations.

   * There is a chicken and egg problem with OpenSSL

   * But even then not all platforms support OpenSSL and if they provide 
an alternative, Perl probably does not support that alternative.

* Supporting more alternatives to OpenSSL is not easy. Probably 
worthwile in itself, but too big a problem to be solved here and now.

So what then was tried as a brainstorm was: How can we provide this on 
as much platforms as possible, in a way that makes sense. So give up on 
doing it always, focus on doing it where possible. From there, Windows 
emerged as a big client platform that is currently troublesome to 
support. It was noted that there is prior art for Win32-specific XS in 
core, and we were looking if this would fit here, to give Win32 specific 
SSL support. That seems possible and a possible way to proceed. So on 
Linux we can rely on wget/curl by the OS, on *BSD something similar can 
be done, Win32 would be covered, meaning you have most of the clientbase 
covered, which seems the best possible.

Also slightly discussed, but not explicitly spoken out, root certificate 
support should come from the OS too. I know a lot about PKI, and it does 
not make sense to do that ourselves. It would open up several attack 
avenues you do not want to worry about, especially revoking a 
compromised certificate is possible, but why go through that trouble 
when the OS does it for you reliably. So there too, this aproach makes 
sense, use whatever is on the platform available to safely install new 

Note that it is still in the brainstorm phase, but I personally think 
the above makes a lot of sense.

> Frankly, this is not upstream perl's problem to solve; but
> efforts can be made to make it an easy "next step" - unless
> there are cases where it absolutely must be in place? I haven't
> read the latest 95% of this thread so maybe this was provided?

We slightly disagree on whether it is or isn't Perls problem to solve 
(if at all possible, which it doesn't seem to be), but given the above 
and how I understand your position, I think we both probably can live 
with this consensus.



Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About