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

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

Thread Previous | Thread Next
Nicholas Clark
December 10, 2021 11:52
Re: OpenSSL alternative support WAS Re: Pre-RFC: support httpsout-of-the-box
Message ID:
On Fri, Dec 10, 2021 at 07:02:15PM +0800, Tom Molesworth via perl5-porters wrote:
> On Fri, 10 Dec 2021 at 18:37, Nicholas Clark <> wrote:
> > both that list and the other mentions of "but use curl or wget" seem to
> > forget Windows. Which I admit that I don't know that much about, but my
> > list of "known unknowns" is already:
> >
> Given the existence of Strawberry Perl and the Linux subsystem, building
> Perl from scratch on Windows seems more like an advanced-user, "you know
> what you're doing already" situation?

Possibly. But it feels wrong to immediately treat Windows for this as
"Somebody Else's Problem" by effectively saying "we solved this for OS/X and
most *nix, but for Win32 you need to get your source from Strawberry".
If Strawberry can find a solution for this, why is it downstream, when we
think it's worth being upstream for "real" operating systems?

> Also, if already use wget/curl if available, and the target
> objective is more-secure-by-default CPAN installation, seems the only
> necessary step for core is perhaps to add some tweaks: refuse
> HTTP-only downloads by default (needs an override otherwise we make life
> harder for situations where caching is desirable).

This seems sensible.

But having seen how OS distributions take the hack-of-least-resistance
combined with *how* stripped down Docker base images are, I wonder if
enough OSes will opt to flip this flag, rather than have perl depend on
more packages - ie they want to ship a "working" perl, and that's easier
by their packaged perl enabling http downloads, than by adding a dependency
from perl to curl or wget binaries.

Or, they don't do either. And then their base image install seems just to
just be broken when end users try to use it to follow instructions published
on the Internet. They might do this because they decide that the system is
insecure if command line tools such as wget are shipped in the "base" image,
but have to ship some sort of "perl" in their "base" image (because other
tooling depends on it), so ship with our defaults and theirs, and CPAN is
broken as standard.

We've had "fun" in the past with OS distributions shipping core perl
packages with some modules removed (notably, *before* *we* removed
it), and even adding new command line flags to the perl binary. That's stuff
that should have been obviously wrong - so obvious that we didn't document
that as "please, no, just don't". So I'm wary that designing something with
a low effort escape hatch intended for individuals who *have* read some
documentation and made a choice, makes it easy for OS package maintainers to
make that (risky) choice for users but then hide it from them.

Nicholas Clark

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