--trusted-host in requirements.txt is ignored · Issue #3799 · pypa/pip (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Closed
akvadrako opened this issue
Jun 15, 2016
· 8 comments · Fixed by #6603
Comments
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
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.
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.
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.
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.
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.
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.
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.
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
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 bot added the auto-locked
Outdated issues that have been locked by automation
label
lock bot locked as resolved and limited conversation to collaborators