Regression: Poetry 1.7 hangs instead of asking to unlock keyring
ilyagr opened this issue · comments
-
Poetry version: 1.7.0
-
Python version: 3.11.6
-
OS version and name: Debian trixie (testing) running in a Chrome OS Linux container
-
pyproject.toml: https://gist.github.com/ilyagr/1bebabebc93e6662d139009d19ed8c1b/edit (includes poetry.lock and detailed command-line output as well).
-
I am on the latest stable Poetry version, installed using a recommended method.
-
I have searched the issues of this repo and believe that this is not a duplicate.
-
I have consulted the FAQ and blog for any relevant entries or release notes.
-
If an exception occurs when executing a command, I executed it again in debug mode (
-vvvoption) and have included the output below.
Issue
This is a follow-up to #1917 and #8227. I also mentioned this briefly in
#1917 (comment)
The bug happens when I run either poetry install or poetry lock.
-
Poetry 1.6.1 behavior: a Gnome (gnome-keyring or seahorse, I'm unsure) window opens and asks to unlock a keyring. If I click cancel (refuse to unlock the keyring), poetry fails with an exception as described in #8227.
-
Current Poetry 1.7 behavior: no Gnome window opens, poetry just freezes for a while.
With Poetry 1.7, I also tried rebooting. After a reboot, a Gnome window does appear. After clicking cancel (refuse to unlock the keyring), it reappears. After clicking cancel ~10 more times, it stops reappearing and hangs again.
rm -r ~/.cache/pypoetry as suggested in #1917 (comment) did not help, with or without reinstalling poetry (via pipx, in my case)
Expected behavior
poetry does not try to unlock the keyring unless it is performing an operation that can't succeed without access to the keyring (e.g., already failed without access to the keyring).
Alternatively, a somewhat inferior option would be to have some way to tell poetry not to try unlocking any keyrings that is easier to discover than the workaround below. Additionally, there would be a user-friendly message suggesting that option whenever unlocking the keyrings doesn't work.
Workaround
The workaround of export PYTHON_KEYRING_BACKEND=keyring.backends.fail.Keyring from #1917 (comment) still works.
Update: #8623 (comment) suggests that poetry config keyring.enabled false is a more permanent workaround.
Command-line output
See https://gist.github.com/ilyagr/1bebabebc93e6662d139009d19ed8c1b for details.
The end of it is often the following printed to stderr:
[keyring.backend] Loading SecretService
[keyring.backend] Loading Windows
[keyring.backend] Loading chainer
[keyring.backend] Loading libsecret
[keyring.backend] Loading macOS
At this point, it hangs forever.
Confirming I'm getting exactly the same behaviour on an Ubuntu dev container with no X server. Both the following workarounds worked for me, but aren't ideal. I do have private repositories in my pyproject.toml, and have configured & tested working access via Github PAT stored in ~/.git-credentials.
export PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyringpyenv shell systemfollowed bypython3 -m keyring --disable
thank you for the workaround, it worked
I have the exact same issue on Ubuntu 20.04.6 LTS and poetry version 1.7.1.
I am running Poetry v1.7.1 / Poetry-Core v1.8.1 on Debian 12 (bookworm) x86_64. I mainly use my computer in text mode and I confirm that poetry hangs when performing an install.
When adding -vvv, it is effectively stuck in unlocking a keyring.
I am running
Poetry v1.7.1 / Poetry-Core v1.8.1on Debian 12 (bookworm) x86_64. I mainly use my computer in text mode and I confirm that poetry hangs when performing an install.When adding
-vvv, it is effectively stuck in unlocking a keyring.
have you try ? it works for me
export PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring
Same issue on Debian 12.
If you're fine with running a prerelease version of poetry you could use this setting to disable the keyring completely.
Edit: No need for running a prerelease version, it is part of the 1.8 release.
Same issue on Ubuntu 22.04 and Poetry 1.8.2. The workaround from @n00bsys0p worked great for me! (I only used the first one and did not test the second one.)
The workaround works. I wonder what is the root cause and whether there will be future Poetry versions addressing this issue 🤔
I ran into this today on Ubuntu 22.04. I think poetry might be trying to get the keyring through a GUI, which a lot of us don't have installed.
It should warn rather than spinning forever. I'm in a headless system, like many. Still an issue with v1.8.2
I found this Poetry setting, which seems likely to be the official way of disabling the keyring, but I haven't had a chance to try it yet.
Nice! Seems like it works. To clarify, you can change it with
poetry config keyring.enabled false
Good to know. The default should be False, just my 2 cents.
oh my, yes this is key, i was trying to troubleshoot a server based install and wondering if a keyring prompt was being expected to pop up where this was hanging (debian12). Thanks for the poetry config example to disable this @damtharvey and @n00bsys0p
Just experienced this myself. Updating poetry and setting the config option to false seems to have worked for me, but there really should be some kind of warning or something instead of hanging forever unless you know to check the extra extra verbose logs...
some kind of warning or something instead of hanging forever unless you know to check the extra extra verbose logs...
I think that's fine. When an ssh command hangs the user is also expected to check the verbose output to see what is wrong. IMO the assumption that there is a working keyring is fine. Most users probably do not care about the keyring at all, so printing checking keyring for everyone would just add noise to the output for most people. Trying to detect a hanging keyring call from within poetry seems overkill to me.
Making the keyring opt-in would solve this issue, but also leave most people less secure since most people will not enable it. I would probably prefer to leave it opt-out. This is a rare issue that is rather easy to analyze and the fix is trivial (setting keyring.enabled false).
I am new to poetry and was facing the exact same issue. It took me quite some time to figure out what is going wrong because I didn't know how long I was supposed to wait or how long checking the keyring would take. The verbose logs therefore only helped for checking where I might be stuck but not that I was actually stuck.
Workaround fixed it.
+1
Looking at bugs like jaraco/keyring#496, it might help if somebody ran keyring --list-backends and tried to debug what causes the issue to happen. Can it be reproduced with the "Command-line utility" described in https://pypi.org/project/keyring/? If so, it's likely a problem in the library and should be reported there.
I no longer have a computer on which this problem occurs, so I cannot do it unless I find a config where it happens.
ssh'd on a headless server got the same issue
it might help if somebody ran keyring --list-backends
hope this helps
❯ keyring --list-backends
keyring.backends.fail.Keyring (priority: 0)
keyring.backends.libsecret.Keyring (priority: 4.8)
keyring.backends.chainer.ChainerBackend (priority: 10)
keyring.backends.SecretService.Keyring (priority: 5)
Still an issue on Ubuntu 22.04 and poetry 1.8.3. Please fix, I spend a lot of time to found this thread.
I encountered this problem on the latest raspian too.
Poetry can't fix a broken keyring setup. Either fix the keyring or disable the use of the keyring in the poetry config.
@Popkornium18 The point is that poetry doesn’t provide any hints about where the issue might be, which can leave people feeling lost. In reality, the issue is often quite simple — once you know where to look. Many users aren’t familiar with keyring or even aware of what it is.
As discussed before, what if poetry could check for keyring and give a warning message?
Poetry does provide hints in verbose modes. It states that it is trying to access the keyring and then it hangs.
The keyring access is part of a library that poetry uses. There is no simple way to test if an available keyring is broken. If it is broken the call to the library code just simply hangs an never returns to the poetry code that might try to handle it.
Just ran into it again (my last time was ~6 months ago) on a fresh raspberry pi.
Is there a way to limit the keyring initialization to just cases where poetry actually, you know, needs keyring access? To me it seems like a 5% case. In my 20 or so projects with poetry (most of them professionally) I have had to access a private repo exactly once. And even then we were using restricted deploy tokens which don't need a secrets manager.
We've just freshly migrated to Poetry from Pipenv and this isn't a very delightful first user experience...
@ilyagr would you mind editing the workaround statement to mention poetry config keyring.enabled false? That seems like the more correct and durable workaround.
Why would keyring.enabled true be a sane default? Improve security practices?
Why would
keyring.enabled truebe a sane default? Improve security practices?
Two reasons:
- Before the setting was introduced, keyring support had always been enabled. Thus, making
truethe default did not result in a behavior change. - Security by default.
Considering how many users have issues with keyring, maybe, we should consider changing the default to false in Poetry 2.0? Although, disabling a security setting by default feels bad...
Considering how many users have issues with keyring, maybe, we should consider changing the default to false in Poetry 2.0? Although, disabling a security setting by default feels bad...
In terms of UX, even emitting a line alerting the user to this potential for an indefinite hang (and the solution) would go a long way. Even better if the conditions are detectable, and the warning is contingent on them? Then you could explore conditionally falling back to a false setting
Adding to what @andrewpollock said, one could also add a prompt before "unlock keyring", warning the user and allowing them to choose between unlocking the keyring and skipping it. Though, I would argue the very first thing to do would be fixing #8761 as this might already solve a good 80% of all issues.
I got another similar problem: somehow, in hindsight, my ssh-agent was down and poetry update was taking forever. With poetry update -vvv I could see that I had a prompt asking for my passphrase!
I really wish poetry could do better in these cases.