Default to the secure option is fair
But the case here is that the "secure option" is being enforced.
If I want to download www.cpan.org/authors/01mailrc.txt.gz, I'm forced to do it securely.
A fresh build of perl (from source) has no capability (AFAICS) to perform such a secure download.
Therefore the cpan utility is initially reliant on some external utility that is capable of a secure download - and there's no guarantee that such an "external utility" exists.
If no such external utility is available to cpan, then cpan is unusable on a fresh build of perl, no matter how you configure it.
That's a rather annoying situation to be in - especially if, as Anonymous Monk asserts elsewhere in this thread, it's a situation created by the cpan.org webserver.
Cheers,
Rob | [reply] |
| [reply]
[d/l] |
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
| [reply] |
