[1.5.0] Charmcraft login not finding keyring
Metadata
Current evaluation
Closed as a headless keyring/session configuration issue; running Charmcraft in dbus-run-session with gnome-keyring unlocked made login succeed. No code fix was recorded.
Resolution: closed not a bug
Reason: The reporter and another affected user confirmed that starting a D-Bus session and unlocking gnome-keyring resolved login. This was an environment configuration problem rather than a Charmcraft code defect.
Evaluated by: mr-cal-bot
No scores available.
Issue body
Hi,
My snap has upgraded to: 1.5.0+7.g51565d8
When I run:
```
$ sudo -u <user> charmcraft login
No keyring found to store or retrieve credentials from.
Full execution log: ...
```
Running the same command with debug option returns:
```
$ sudo -u <user> charmcraft login -v
2022-03-18 15:52:12.112 Starting charmcraft version 1.5.0+7.g51565d8
2022-03-18 15:52:12.112 Logging execution to
2022-03-18 15:52:12.199 No keyring found to store or retrieve credentials from.
2022-03-18 15:52:12.200 Traceback (most recent call last):
2022-03-18 15:52:12.200 File "/snap/charmcraft/849/lib/charmcraft/commands/store/store.py", line 179, in __init__
2022-03-18 15:52:12.200 self._client = Client(charmhub_config.api_url, charmhub_config.storage_url)
2022-03-18 15:52:12.200 File "/snap/charmcraft/849/lib/charmcraft/commands/store/client.py", line 57, in __init__
2022-03-18 15:52:12.200 super().__init__(
2022-03-18 15:52:12.200 File "/snap/charmcraft/849/lib/craft_store/store_client.py", line 84, in __init__
2022-03-18 15:52:12.200 super().__init__(
2022-03-18 15:52:12.200 File "/snap/charmcraft/849/lib/craft_store/base_client.py", line 65, in __init__
2022-03-18 15:52:12.200 self._auth = Auth(
2022-03-18 15:52:12.200 File "/snap/charmcraft/849/lib/craft_store/auth.py", line 103, in __init__
2022-03-18 15:52:12.200 raise errors.NoKeyringError()
2022-03-18 15:52:12.200 craft_store.errors.NoKeyringError: No keyring found to store or retrieve credentials from.
```
Which fails in this check:
```
...
self._keyring = keyring.get_keyring()
# This keyring would fail on first use, fail early instead.
if isinstance(self._keyring, keyring.backends.fail.Keyring): ## <<<<----------------------
raise errors.NoKeyringError()
...
```
However, if I manually install the same keyring lib (23.5.0) and just run it, I get:
```
$ sudo -u <user> python3 -c "import keyring; key=keyring.get_keyring(); print(key)"
keyring.backends.libsecret.Keyring (priority: 4.8)
```
I was expecting to actually see ```keyring.backends.fail.Keyring```, just like it happens with auth.py above.
Nonetheless, I'd expect ```charmcraft login``` to always work, even if I do not have a keyring. Or at least give me exact steps of what I should be doing as an user to setup the keyring and login.
Also, I am using "sudo" just because my original user was logged in with charmcraft when we used to have v1.4.0 and I could not reproduce the issue with that user. When running with sudo, it likely misses some of the variables needed to correctly configure charmcraft.
Workaround:
```
$ keyring --list # select one of the keyrings
$ sudo -u <user> PYTHON_KEYRING_BACKEND=<chose-keyring> charmcraft login
```
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha | — | closed not a bug | Closed as a headless keyring/session configuration issue; running Charmcraft in dbus-run-session with gnome-keyring unlocked made login succeed. No code fix was recorded. | |
| stealth/space-bunny-alpha | — | closed not a bug | Resolved as a headless keyring configuration issue: running login in dbus-run-session with gnome-keyring unlocked worked. No fixing PR or commit was recorded. | |
| qwen3.6-35b-a3b-mtp-q6 | — | — | Closed without a code fix. Identified as an environmental configuration issue. Users resolved it by using dbus-run-session or explicitly setting PYTHON_KEYRING_BACKEND to bypass automatic keyring detection failures. | |
| qwen/qwen3.6-35b-a3b | — | — | Closed. Not code-fixed; users resolved the keyring detection failure by setting PYTHON_KEYRING_BACKEND or running charmcraft in a dbus session with gnome-keyring-daemon. Maintainers directed users to upstream keyring documentation for headless environments. | |
| qwen/qwen3.6-35b-a3b | — | — | Closed. The failure stems from keyring library behavior in headless or VM environments, not a charmcraft bug. Resolved by setting PYTHON_KEYRING_BACKEND or executing commands via dbus-run-session with gnome-keyring-daemon. | |
| qwen3.6-35b-a3b-mtp-q6 | — | — | Closed as a headless environment config issue. Users must run charmcraft in a dbus session and unlock gnome-keyring. A dbus-run-session and gnome-keyring-daemon workaround was confirmed effective. |
Update history
No update history recorded yet.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #672 charmcraft 1.4.0: impossible to login to charmhub | charmcraft | closed | Closed as intended behavior: the headless remote host had no local keyring, so Charmcraft could not persist credentials; exporting credentials was the supported workaround. | |
| #631 v1.4.0 - failing to login and use anything related to credentials | charmcraft | closed | No code fix was identified; Charmcraft 1.4.0 could not access the desktop keyring from its snap environment. Installing gnome-keyring restored login on Kubuntu, while exported credentials offered another workaround. | |
| #901 Charmcraft login on remote device has unhelpful error message | charmcraft | closed | Superseded by canonical/craft-store#58 and fixed there through PR #390 (d87f1bd), which converts keyring initialization failures into KeyringUnlockError. | |
| #844 Cannot use charmcraft login | charmcraft | closed | Login failed over SSH ('Prompt dismissed'). Maintainer closed it pointing to Charmhub discourse instructions for authenticating in remote environments; no code change. |