fallback to HTTP-only when TLS is unavailable #1
Conversation
cpanm will fall back to (non-TLS) HTTP only requests when all default options are used AND TLS support is unavailable, but please note that, for security reasons, if TLS support is available but broken (e.g. invalid/expired certificates), requests will fail unless you explicitly use --insecure. Also note that if you use --insecure but provide custom HTTPS URLs, they will still fail if TLS support is not available. Similarly, if you provide custom HTTP-only URLs, they will go over plain HTTP and not require TLS support.
|
Note the main PR that matters is the one targeting master branch |
I just wanted to make sure this can be built and fatpacked properly before merging. I know the one that matters is the one targetting master, I just figured by doing the fallback also on the devel branch we make things easier for miyagawa, as he can keep both in sync. (if neither of you have trouble with this patch, once we merge I'll update the one targetting the master branch as well) |
| $self->diag_fail( join( ', ', @protocol )." not supported by available HTTP Clients." ); | ||
| } | ||
|
|
||
| $backend->new(agent => "Menlo/$Menlo::VERSION", verify_SSL => 1); |
There was a problem hiding this comment.
Maybe --insecure should set verify_SSL => 0, in case the mirror used is only available on https and the user doesn't care about checking the host certs.
There was a problem hiding this comment.
Ignore that, just saw the # HTTPTinyish does not provide an option to disable certificates check, let's switch to http on demand comment above
|
Btw: Are we aware of some actual examples of situations when an automatic fallback to HTTP is needed? Since a fallback is imho not great from a security angle, should we find some example of what we're optimizing for, and why using This would be useful for testing as well. During the previous effort to change verify_SSL to 1 by default in HTTP::Tiny, there were several discussions that mentioned to a hypothetical situation where you'd bootstrap a perl installation on environments without a working SSL setup - but didn't actually see an example of those, and I'd always felt that it is awkward to optimize for those cases. |
This patch will make cpanm fall back to (non-TLS) HTTP only requests when all default options are used AND TLS support is unavailable, with the following message:
WARNING: TLS support not found. Falling back to insecure HTTP-only requestsPlease note that, for security reasons, if TLS support is available but broken (e.g. invalid/expired certificates), requests will fail unless you explicitly use --insecure.
Also note that if you use --insecure but provide custom HTTPS URLs, they will still fail if TLS support is not available.
Similarly, if you provide custom HTTP-only URLs, they will go over plain HTTP and not require TLS support.