jaraco / jaraco/keyring

--mode creds switch not working on macos

Open
#711 2 comments 3 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
1.5k
Forks
196
PR merge metrics
No merged PRs in 30d

Description

Currently the users guide has pretty much no information on the use of the `--mode creds` command line switch for the CLI interface for keyring. This makes it difficult to understand how this particular option is expected to work.

In particular, I was attempting to make use of keyring on MacOS as a backend secret store for the [uv tool](https://github.com/astral-sh/uv), which - [under the hood](https://github.com/astral-sh/uv/blob/3dad8fef2d516e8d342bab37063267a6c8fe6c9b/crates/uv-auth/src/keyring.rs#L87) - makes use of the `keyring --mode creds` feature for extrapolating the credentials for a specific pypi repository. At first glance this seemed easy enough to set up, were it not for the fact that all of my local ad-hoc tests on my MacOS Macbook weren't working.

I have just recently started testing keyring on my MacBook Pro, running the latest version of MacOS (Sequoia v15.3.2), and am encountering a problem which I am unsure if it is a bug or if I'm simply not using the tool properly. Based on the documentation for the `--mode creds` switch, it is my understanding that the `get` command should return both the username / email ID and password associated with a given server, even when no username is provided. However, this does not seem to be the case. Consider the following example use case:

**Expected Behavior**

```
keyring set https://my.pypi.server fubar@com
> ... enter password when prompted
keyring get --mode creds https://my.pypi.server
> both email and password should be presented
```

**Actual Behavior**
```
keyring set https://my.pypi.server fubar@com
> ... enter password when prompted
keyring get --mode creds https://my.pypi.server
> nothing is returned and a non-zero return code is given
```

If, however, I include the username on the console I get the expected output

```
keyring get --mode creds https://my.pypi.server fubar@com
> both email and password are presented as expected
```

This presents a particularly troublesome problem for tools that rely on this behavior, like [uv](https://github.com/astral-sh/uv), which - [under the hood](https://github.com/astral-sh/uv/blob/3dad8fef2d516e8d342bab37063267a6c8fe6c9b/crates/uv-auth/src/keyring.rs#L87) - makes use of the `keyring --mode creds` feature for extrapolating the credentials for a specific pypi repository. So while it appears as though I have my system configured properly for `uv` to work, in practice it doesn't produce the expected results. It took me a while to isolate the root cause to `keyring` CLI application.

In addition, it would be helpful if the users guide for your tool included some more detailed explanations around the behavior of this particular switch. Based on my initial investigation, it would appear that how the `get` command works is heavily dependent on the specific backend implementation that is being used, so I suspect there may be some additional variation here on different platforms (unconfirmed of course). Either way, it would be helpful if this information were present up front in the docs somewhere so that users don't have to troll the source code to figure it out.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the users guide and the CLI entry point for `get --mode creds`; reproduce the documented commands on macOS and inspect how the selected backend handles a missing username. Done means the behavior is corrected or clearly documented, with the guide explaining backend and platform differences and the relevant command returning the expected credentials.

Written by the indexing model from the issue text.

Assessment

Tech stack
macos, python
Domain
cli, documentation
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
50/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.