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

--trusted-host in requirements.txt is ignored #3799

Closed
akvadrako opened this issue Jun 15, 2016 · 8 comments

Comments

@akvadrako
Copy link

commented Jun 15, 2016

According to the release notes and the old issue #2822, trusted-host should work in a requirements.txt file, but it has no effect. I can't find it documented but since it doesn't generate a warning, I assume it's still supported.

  • Pip version: 8.1.2
  • Python version: 2.7.5
  • Operating System: CentOS 7.2.1511

This is the requirements.txt file:

--trusted-host doubly.so
--index-url https://doubly.so/pub/py/simple
dummy_test

It does not work unless I give the trusted-host option on the command-line:

[14:06:19] pip install -r requirements.txt 
DEPRECATION: --allow-all-external has been deprecated and will be removed in the future. Due to changes in the repository protocol, it no longer has any effect.
Collecting dummy_test (from -r requirements.txt (line 3))
  Could not fetch URL https://doubly.so/pub/py/simple/dummy-test/: There was a problem confirming the ssl certificate: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:765) - skipping
  Could not find a version that satisfies the requirement dummy_test (from -r requirements.txt (line 3)) (from versions: )
No matching distribution found for dummy_test (from -r requirements.txt (line 3))

[1][14:06:21] pip install --trusted-host doubly.so -r requirements.txt 
DEPRECATION: --allow-all-external has been deprecated and will be removed in the future. Due to changes in the repository protocol, it no longer has any effect.
Collecting dummy_test (from -r requirements.txt (line 3))
Installing collected packages: dummy-test
Successfully installed dummy-test-0.1.3
@countergram

This comment has been minimized.

Copy link

commented Jun 27, 2016

I am also having this issue. Based on a quick scan of pip source, I do not believe --trusted-host is being ignored per se in requirements.txt, just that it is treated differently than it is on the command line, which is definitely confusing and possibly dangerous.

It appears (again, quick scan) that on the command line --trusted-host bypasses cert validation by specially setting up InsecureHTTPAdapter, whereas in requirements.txt it is merely added to finder.secure_origins which is aimed at using http rather than https URLs. These are two quite different things.

The fact that pip uses two different mechanisms for the same option is disturbing.

@frimik

This comment has been minimized.

Copy link

commented Aug 15, 2016

trusted-host options is for command-line or pip.conf only. It has no business being allowed in requirements.txt as that defeats the purpose of protecting your deployment/build etc.

@akvadrako

This comment has been minimized.

Copy link
Author

commented Aug 15, 2016

If you are worried about security then index-url in requirements.txt is the bigger threat. There is no point in spoofing an HTTPS connection when you can just use a custom url.

@dstufft

This comment has been minimized.

Copy link
Member

commented Aug 15, 2016

Malicious requirements.txt files are not part of the threat model pip operates under. The only way a requirements.txt file gets read is if the end user includes it explicitly via -r to the pip command line or via -r in a requirements.txt that was explicitly included via the pip command line.

@hazmat345

This comment has been minimized.

Copy link

commented Dec 8, 2017

This seems to still be an issue for me with Pip 9.0.1.

Are there any thoughts about what the correct behavior should be? For me the behavior that occurs when --trusted-host is on the command line (using InsecureHTTPAdapter) is better since that allows for self-signed certificates, but I'm worried there might be issues that I'm not seeing.

@pradyunsg

This comment has been minimized.

Copy link
Member

commented Mar 5, 2018

Out of the two current behaviours, I'm not sure which one is better. I guess that discussion is something we can defer until someone actually has the interest to opens a PR for this. For that reason, I've labelled this issue as an "deferred till PR".

This label is essentially for indicating that further discussion related to this issue should be deferred until someone comes around to make a PR. This does not mean that the said PR would be accepted - it has not been determined the change would be useful to pip and that decision has been deferred until the PR is made.

@cjerdonek

This comment has been minimized.

Copy link
Member

commented Jun 13, 2019

I posted PR #6603 for this. I implemented the PR so that --trusted-host inside a requirements file has the same behavior as if it were added on the command-line. This seems more intuitive because of the consistency, etc.

@cjerdonek

This comment has been minimized.

Copy link
Member

commented Jun 14, 2019

FYI, in my implementation of this in PR #6603, I added an INFO log message whenever a --trusted-host gets added from a requirements file (and from which file). So that will help with visibility issues as to which hosts are getting used.

HaluskaR pushed a commit to LLNL/Sina that referenced this issue Jun 26, 2019

SIBO-650: Restored insecure option to curl; added trusted host option
pip bug

Joe found an open bug indicating pip doesn't recognize the trusted host option in requirements files (pypa/pip#3799) so add the option to the pip command in the Makefile when necessary.  This includes restoring the insecure (i.e., -k) curl check.

@lock lock bot added the S: auto-locked label Jul 14, 2019

@lock lock bot locked as resolved and limited conversation to collaborators Jul 14, 2019

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