|
in reply to Re^6: HSTS policy breaks cpan utility on Windows
in thread HSTS policy breaks cpan utility on Windows
Yes, Core should include SSL capabilities from the start
This would mean that perl would be dependent upon the SSL library on which the SSL-compatible CORE relies - either that, or the perl source has to include its own portable SSL code.
I've had enough trouble with OpenSSL (and other libraries) in the past to be sympathetic to the view that perl should remain independent of all third party libraries, and I wouldn't like to burden the perl developers with the task of incorporating portable SSL code into the perl source.
Cheers,
Rob |
Re^8: HSTS policy breaks cpan utility on Windows
by cavac (Parson) on Nov 26, 2019 at 12:40 UTC
|
Couldn't "Configure" just test for the availability of a compatible SSL library and build/install/test the SSL modules only if the system has one of those libs?
The problem with not having SSL from the start is sort of a big one: The first time you use CPAN, you are doing it from an untrusted source that makes it easy to MITM attack.
perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'
| [reply]
[d/l] |
|
|
Couldn't "Configure" just test for the availability of a compatible SSL library and build/install/test the SSL modules only if the system has one of those libs?
I would think that could be done if someone were prepared to make the effort.
Maybe the perl developers should be asked about this ?
I don't think it's a job I'd like to take on, even if I thought I had the capability.
I now have wget on all 4 of my home systems (including Windows).
With 'urllist' set to 'https://www.cpan.org' (as marto suggested earlier) I'm now set up so that CPAN on any fresh installation of perl will use wget over https.
Cheers,
Rob
| [reply] |
|
