Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Which is the recommended value of trusted host when the URL contains port #6705

Closed
frostming opened this issue Jul 13, 2019 · 6 comments · Fixed by #6709

Comments

@frostming
Copy link
Contributor

@frostming frostming commented Jul 13, 2019

Environment

  • pip version:19.0.3
  • Python version:3.7
  • OS:macOS

Description
When the index URL contains port, the behavior of trusted is inconsistent depending on it's HTTP or HTTPS.

For HTTP indexes, Pip complains that trusted host should be sans-port. However, using port doesn't work for HTTPS indexes, throwing an SSL error.

Expected behavior
There should only one way to specify trusted host.

How to Reproduce
See the following steps. Note for the index URLs and trusted host values.

Output

HTTP

$ pip install -i http://localtest.me:5000 urllib3 --trusted-host localtest.me:5000
Looking in indexes: http://localtest.me:5000
Collecting urllib3
  The repository located at localtest.me is not a trusted or secure host and is being ignored. If this repository is available via HTTPS we recommend you use HTTPS instead, otherwise you may silence this warning and allow it anyway with '--trusted-host localtest.me'.
  Could not find a version that satisfies the requirement urllib3 (from versions: )
No matching distribution found for urllib3

HTTPS

$ pip install -i https://localtest.me:8088 urllib3 --trusted-host localtest.me
Looking in indexes: https://localtest.me:8088
Collecting urllib3
  Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1076)'))': /urllib3/
@cjerdonek

This comment has been minimized.

Copy link
Member

@cjerdonek cjerdonek commented Jul 13, 2019

Can you show the output of the other two of the four cases?

$ pip install -i http://localtest.me:5000 urllib3 --trusted-host localtest.me
$ pip install -i https://localtest.me:8088 urllib3 --trusted-host localtest.me:5000
@frostming

This comment has been minimized.

Copy link
Contributor Author

@frostming frostming commented Jul 13, 2019

@cjerdonek

This comment has been minimized.

Copy link
Member

@cjerdonek cjerdonek commented Jul 14, 2019

Maybe one approach for this can be--

  1. Get --trusted-host with no port working for both,
  2. Deprecate passing a port to --trusted-host (can be done at the same time as (1)), and then
  3. Error out if a port is passed to --trusted-host after the deprecation period
@frostming

This comment has been minimized.

Copy link
Contributor Author

@frostming frostming commented Jul 14, 2019

@cjerdonek I am curious about the reason why w/o port is preferred over the other.

From a rough digging into the code, I found that an insecure host is bypassed using the requests' mount method:

def add_insecure_host(self, host):
# type: (str) -> None
self.mount('https://{}/'.format(host), self._insecure_adapter)

At that point, we don't know the exact port of the host, if no port is provided through trusted-host. Though there is an easy fix to remove the trailing slash in the URL(the matching uses startswith check), however, it will introduce extra risk to match a different host, e.g. https://example.com v.s https://example.com.cn, which is not expected.

Therefore, it is more straightforward to always use host with port. But I am also OK with the decisions made by maintainers if you insist. I am glad to send a PR then.

@cjerdonek

This comment has been minimized.

Copy link
Member

@cjerdonek cjerdonek commented Jul 14, 2019

I am curious about the reason why w/o port is preferred over the other.

I wasn't expressing a preference but rather just making a suggestion to start talking about possible solutions. There are a couple factors that seem important: (1) Is the port looked at when using --trusted-host, and if not, should it be? If the answer to both of these questions is no, then I think it would be better not to accept a port. Otherwise, it gives the user the false impression that the port matters. (2) The option is currently documented as being a "hostname" and doesn't mention a port:

--trusted-host <hostname>: Mark this host as trusted, even though it does not have valid or any HTTPS.

@frostming

This comment has been minimized.

Copy link
Contributor Author

@frostming frostming commented Jul 14, 2019

@cjerdonek Makes sense now. --trusted-host does expect a host only. PR is on the way.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
2 participants
You can’t perform that action at this time.