Front page | perl.perl5.porters |
Postings from December 2021
Op 12-12-2021 om 04:35 schreef Oodler 577: > * Craig A. Berry <craig.a.berry@gmail.com> [2021-12-10 16:22:27 -0600]: > >> On Fri, Dec 10, 2021 at 3:59 PM Martijn Lievaart <m@rtij.nl> wrote: >>> >>> Op 10-12-2021 om 22:30 schreef Craig A. Berry: >>> >>> [1] https://docs.microsoft.com/en-us/windows/win32/api/wininet/nf-wininet-internetreadfile >>> >>> >>> 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 packages. 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. HTH, M4Thread Previous | Thread Next