Front page | perl.perl5.porters |
Postings from December 2021
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 <nick@ccl4.org> 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 CPAN.pm 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 CPAN.pm 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 CGI.pm, *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 ClarkThread Previous | Thread Next