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
Closed

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

frostming opened this issue Jul 13, 2019 · 6 comments · Fixed by #6709
Labels
auto-locked Outdated issues that have been locked by automation C: cli Command line interface related things (optparse, option grouping etc) C: download About fetching data from PyPI and other sources type: bug A confirmed bug or unintended behavior

Comments

@frostming
Copy link
Contributor

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/
@triage-new-issues triage-new-issues bot added the S: needs triage Issues/PRs that need to be triaged label Jul 13, 2019
@cjerdonek cjerdonek added C: cli Command line interface related things (optparse, option grouping etc) C: download About fetching data from PyPI and other sources type: bug A confirmed bug or unintended behavior labels Jul 13, 2019
@triage-new-issues triage-new-issues bot removed S: needs triage Issues/PRs that need to be triaged labels Jul 13, 2019
@cjerdonek
Copy link
Member

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
Copy link
Contributor Author

frostming commented Jul 13, 2019 via email

@cjerdonek
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

frostming commented Jul 14, 2019

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

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Sep 14, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Sep 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation C: cli Command line interface related things (optparse, option grouping etc) C: download About fetching data from PyPI and other sources type: bug A confirmed bug or unintended behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants