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 · Fixed by #6603
Closed

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

akvadrako opened this issue Jun 15, 2016 · 8 comments · Fixed by #6603
Labels
auto-locked Outdated issues that have been locked by automation type: enhancement Improvements to functionality

Comments

@akvadrako
Copy link

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

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

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

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

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

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

pradyunsg 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.

@pradyunsg pradyunsg added state: awaiting PR Feature discussed, PR is needed type: enhancement Improvements to functionality resolution: deferred till PR Further discussion will happen when a PR is made and removed state: awaiting PR Feature discussed, PR is needed labels Mar 5, 2018
@cjerdonek
Copy link
Member

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 cjerdonek removed the resolution: deferred till PR Further discussion will happen when a PR is made label Jun 13, 2019
@cjerdonek
Copy link
Member

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
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 auto-locked Outdated issues that have been locked by automation 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.
Labels
auto-locked Outdated issues that have been locked by automation type: enhancement Improvements to functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants