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

pip 8.1.1 fails to use credentials specified inside the ~/pypirc file for downloading packages #3643

Closed
ssbarnea opened this issue May 2, 2016 · 9 comments
Labels
auto-locked Outdated issues that have been locked by automation

Comments

@ssbarnea
Copy link
Contributor

ssbarnea commented May 2, 2016

It seems that pip 8.1.1 fails to load credentials from inside the ~/.pypirc and prompts for the user and password instead.

I deployed an private pypi-server which allows anonymous listing about requires basic authentication for upload and download.

Still pip seems to prompt me for the user and password, even if these are configured. If I introduce them it works but that's clearly not an option, especially as I am trying to configure continuous integration.

[distutils]
index-servers = custom

[custom]
repository: https://pypi.example.com
username: johndoe
password: changeme

What is even more interesting is that python setup.py sdist upload -r custom works without prompting for any password, a clear indication that it does successfully load and use them.

@atrepca
Copy link

atrepca commented May 10, 2016

~/.pypirc is used by distutils for uploading packages: docs. Pip uses ~/.pip/pip.conf; the docs aren't explicit about this but for basic auth the file should be:

[global]
extra-index-url = https://johndoe:[email protected]/simple/

hth,

@ssbarnea
Copy link
Contributor Author

I know that putting credentials in the url works with pip.conf but this is a huge security risk because the URL is displayed in the console and output logs in lots and lots of cases.
This is a no-no from the security point of view.

@atrepca
Copy link

atrepca commented May 10, 2016

Not sure what you mean. Here's my pip.conf:

-> ~ $ cat ~/.pip/pip.conf 
[global]
extra-index-url = http://redacted:[email protected]/simple/
trusted-host = my-pypi-server.example.com

Pulling from my PyPI server which is behind basic auth:

-> ~ $ sudo pip install my_private_package
Collecting my_private_package
  Downloading http://my-pypi-server.example.com/packages/my_private_package-0.0.8.tar.gz
Collecting celery>=3.0 (from my_private_package)
  Downloading celery-3.1.23-py2.py3-none-any.whl (520kB)
    100% |████████████████████████████████| 522kB 465kB/s 
Collecting pagoda (from my_private_package)
(...)

No credentials in clear anywhere, besides the pip.conf flat file. Also, I don't have a ~/.pypirc file on my local.

hth,

@ssbarnea
Copy link
Contributor Author

I will provide more info tomorow, we use the default index url, not the extra one. I will find a way to replicate the issue.

@atrepca
Copy link

atrepca commented May 11, 2016

Just tested and the output is the same with --index-url, I'm using --extra-index-url as recommended by the PyPI server docs, known limitations:

It does not handle misspelled packages as pypi-repo does, therefore it is suggested to use it with --extra-index-url instead of --index-url (see pypiserver/pypiserver#38)

@dstufft
Copy link
Member

dstufft commented Sep 7, 2016

~/.pypirc is for distutils (and twine) and not for pip.

@dstufft dstufft closed this as completed Sep 7, 2016
@ahasha
Copy link

ahasha commented Dec 6, 2016

I recreated @ssbarnea's issue about credentials displaying in the clear by running pip install with the verbose option. Using pip 8.1.2 and python 2.7.12:

$ pip install -v somepackage
Collecting somepackage
  1 location(s) to search for versions of somepackage:
  * https://redacted:[email protected]/simple/somepackage
  Getting page https://redacted:[email protected]/simple/somepackage/
...

This was with the index-url option set, but it also happens with extra-index-url.

@expobrain
Copy link
Contributor

#6295 fixes this issue

@lock
Copy link

lock bot commented May 28, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label May 28, 2019
@lock lock bot locked as resolved and limited conversation to collaborators May 28, 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
Projects
None yet
Development

No branches or pull requests

5 participants