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.

Sign up for GitHub

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

Jump to bottom

pip still prompts for username/password even when keyring is configured #12661

Open
1 task done
Time0o opened this issue Apr 29, 2024 · 2 comments
Open
1 task done

pip still prompts for username/password even when keyring is configured #12661

Time0o opened this issue Apr 29, 2024 · 2 comments
Labels
C: keyring Related to pip's keyring integration S: needs triage Issues/PRs that need to be triaged type: bug A confirmed bug or unintended behavior

Comments

@Time0o
Copy link

Time0o commented Apr 29, 2024

Description

I'm trying to download a package from a GitLab registry using credentials stored via keyring. I believe I am following the documentation but pip neither uses the keyring credentials nor displays an error and instead just prompts for username/password.

$ which pip
/home/timo/python_venvs/my_venv/bin/pip
$ which keyring
/home/timo/python_venvs/my_venv/bin/keyring
$ echo <MY_TOKEN> | keyring set https://gitlab.com/api/v4/groups/<MY_GROUP_ID>/-/packages/pypi/simple <MY_TOKEN_NAME>
$ pip install --keyring-provider import -i https://gitlab.com/api/v4/groups/<MY_GROUP_ID>/-/packages/pypi/simple <MY_PACKAGE>
User for gitlab.com:
...

Expected behavior

pip uses the credentials stored in keyring.

pip version

24.0

Python version

3.10.12

OS

Ubuntu 22.04.4 LTS

How to Reproduce

  1. Install pip and keyring
  2. Create a GitLab package registry and upload a Python package to it
  3. Create a GitLab access token with read_api rights
  4. Store the token via keyring
  5. Run pip install --keyring-provider import -i https://gitlab.com/api/v4/groups/<MY_GROUP_ID>/-/packages/pypi/simple <MY_PACKAGE>

Output

No response

Code of Conduct
@Time0o Time0o added S: needs triage Issues/PRs that need to be triaged type: bug A confirmed bug or unintended behavior labels Apr 29, 2024
jfly added a commit to jfly/pip that referenced this issue Jun 5, 2024
@jfly
Add support for pulling username from keyring subprocess
dab840a 
This fixes pypa#12543 (and probably
pypa#12661).

Somewhat confusingly, when using using `PIP_KEYRING_PROVIDER=import`,
pip was able to fetch both a username and a password from keyring, but
when using `PIP_KEYRING_PROVIDER=subprocess`, it needed the username.

I opted not to write a new test for this, as the existing
[test_prompt_for_keyring_if_needed](https://github.com/pypa/pip/blob/86b8b23c1eaaac5c420a28519daf91de830f1182/tests/functional/test_install_config.py#L392)
feels sufficient to me.

TODO/need feedback:
- I haven't implemented any "feature detection" to see if the `keyring`
  subprocess supports `--mode=creds`. This feature was added quite
  recently
  (jaraco/keyring@7830a64
  landed in keyring v25.2.0). It looks like there's an older `getcreds`
  subcommand which we could probably feature detect as well. I
  personally would inclined to keep things simple and only support the
  latest version of the `keyring` cli, but I will gladly implement
  whatever y'all think is best.
- Should I add a news entry about this?
jfly added a commit to jfly/pip that referenced this issue Jun 5, 2024
@jfly
Add support for pulling username from keyring subprocess provider
5703f04 
This fixes pypa#12543 (and probably
pypa#12661).

Somewhat confusingly, when using using `PIP_KEYRING_PROVIDER=import`,
pip was able to fetch both a username and a password from keyring, but
when using `PIP_KEYRING_PROVIDER=subprocess`, it needed the username.

I opted not to write a new test for this, as the existing
[test_prompt_for_keyring_if_needed](https://github.com/pypa/pip/blob/86b8b23c1eaaac5c420a28519daf91de830f1182/tests/functional/test_install_config.py#L392)
feels sufficient to me.

TODO/need feedback:
- I haven't implemented any "feature detection" to see if the `keyring`
  subprocess supports `--mode=creds`. This feature was added quite
  recently
  (jaraco/keyring@7830a64
  landed in keyring v25.2.0). It looks like there's an older `getcreds`
  subcommand which we could probably feature detect as well. I
  personally would inclined to keep things simple and only support the
  latest version of the `keyring` cli, but I will gladly implement
  whatever y'all think is best.
- Should I add a news entry about this?
jfly added a commit to jfly/pip that referenced this issue Jun 5, 2024
@jfly
Add support for pulling username from keyring subprocess provider
1bf71c8 
This fixes pypa#12543 (and probably
pypa#12661).

Somewhat confusingly, when using using `PIP_KEYRING_PROVIDER=import`,
pip was able to fetch both a username and a password from keyring, but
when using `PIP_KEYRING_PROVIDER=subprocess`, it needed the username.

I opted not to write a new test for this, as the existing
[test_prompt_for_keyring_if_needed](https://github.com/pypa/pip/blob/86b8b23c1eaaac5c420a28519daf91de830f1182/tests/functional/test_install_config.py#L392)
feels sufficient to me.

TODO/need feedback:
- I haven't implemented any "feature detection" to see if the `keyring`
  subprocess supports `--mode=creds`. This feature was added quite
  recently
  (jaraco/keyring@7830a64
  landed in keyring v25.2.0). It looks like there's an older `getcreds`
  subcommand which we could probably feature detect as well. I
  personally would inclined to keep things simple and only support the
  latest version of the `keyring` cli, but I will gladly implement
  whatever y'all think is best.
@jfly jfly mentioned this issue Jun 5, 2024
Open
@jfly
Copy link
Contributor

jfly commented Jun 5, 2024 •
edited
Loading

Edit: nevermind, I was wrong: @Time0o is using --keyring-provider import, not subprocess.

@Time0o, this looks likely to be a duplicate of #12543. When using keyring as a subprocess, it can't discover the username. Workarounds are to either change your index url to include a username, or use keyring with the import provider, which does have support for keyring's get_credentials functionality to fetch both a password and a username.

@Darsstar
Copy link
Contributor

Darsstar commented Jun 5, 2024

@Time0o, this looks likely to be a duplicate of #12543. When using keyring as a subprocess, it can't discover the username. Workarounds are to either change your index url to include a username, or use keyring with the import provider, which does have support for keyring's get_credentials functionality to fetch both a password and a username.

The reproducer includes --keyring-provider import, so I don't think your PR is relevant.

jfly added a commit to jfly/pip that referenced this issue Aug 21, 2024
@jfly
Add support for pulling username from keyring subprocess provider
59ad998 
This fixes pypa#12543 (and probably
pypa#12661).

Somewhat confusingly, when using using `PIP_KEYRING_PROVIDER=import`,
pip was able to fetch both a username and a password from keyring, but
when using `PIP_KEYRING_PROVIDER=subprocess`, it needed the username.

I had to rework the existing tests quite a bit to fit with this new
behavior, as it's now OK to ask for a username/password for an index
even if you don't have a username. This is why `KeyringSubprocessResult`
now subclasses `KeyringModuleV2`. While I was in here, I opted to remove
the "fixtures" values from `KeyringModuleV2` by introducing this new
`add_credential` contextmanager. IMO, they were hurting the readability
of our tests: you had to jump around quite a bit to see what the
contents of the keyring would be during our tests. It also forced all
our tests to play nicely with the same fixtures values, which IMO was an
unnecessary constraint.

Note: per the discussion
[here](pypa#12748 (comment)),
I've opted not to implement any "feature detection" to see if the
`keyring` subprocess supports `--mode=creds`. For the record, this
feature was added in
jaraco/keyring@7830a64,
which landed in keyring v25.2.0.
@ichard26 ichard26 added the C: keyring Related to pip's keyring integration label Dec 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C: keyring Related to pip's keyring integration S: needs triage Issues/PRs that need to be triaged type: bug A confirmed bug or unintended behavior
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@Darsstar @jfly @Time0o @ichard26