Keyring access requested although non-publishing operations do not need any credentials.

[real-yfprojects]

• Poetry version: 1.8.0.dev0 (6f9de73)
• Python version: 3.8.10
• OS version and name: Kubuntu
• pyproject.toml: Any minimal working configuration, no dependencies are required.

• 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 (-vvv option) and have included the output below.

Issue

In its essence this is the same as #1917 and closely linked to #8623.

Can you summarize the problem?

For any http request made by poetry it will hit the keyring for possible credentials to send along (presumably to support private repositories and registries). However this has the consequents that poetry needs keyring access for almost all operations although most operations do not require any credentials. This is bad. Quoting from #1917 (comment):

I think people should be careful about granting programs access to things they should not need to access. This behavior is an example of a problem that makes that hard to achieve.

Why was #1917 closed?

Very good question. The maintainers apparently thought fixing the symptoms would also fix the underlying problem. See #8078 (comment) and #8227. As a matter of fact the underlying issue now reappears in a different disguise.

What's the new symptom?

#8227 fixed the problem where poetry just exited when the keyring access was denied. In the current version it ignores the denial and sends the http request without credentials.
However for the next http request it will try to access the keyring again. For a command like poetry add pytest this will result in uncountable popups requesting keyring access that one has to deny (hit cancel in my case) one after another. This makes poetry unusable without granting keyring access. It is safe to say that #8227 practically didn't fix anything.

What would be an actual fix?

I can already imagine the maintainers putting forward fixes for this new problem instead of fixing the underlying issue.
The sane way of fixing this goes like that:
Prioritize the uses cases of the majority. Only a minority of packages need credentials for resolving dependencies. For those users the configuration file format could be adjusted so that they can specify when credentials are required. For all other users poetry shouldn't hit the keyring at all when running lock, install, add, ... However for poetry publish credentials may be requested for all users.

[dimbleby]

close enough to duplicating #8623 that I doubt it's useful to track separately.

pull requests welcome, I assume

[real-yfprojects]

close enough to duplicating #8623 that I doubt it's useful to track separately.

Yeah, I decided to open this one anyway because I found #8623 lacking in some aspects. And at least in the title, focusses more on the symptoms again.

[radoering]

Yeah, I decided to open this one anyway because I found #8623 lacking in some aspects.

I think I'm fine with this. Afaik, the other issue describes a specific regression and this issue is more general. So the other issue might be resolved without resolving this one.

I'm not that deep into this keyring topic, but I suppose #7038 (comment) might be a reason why we are trying to use keyring even if it's not necessary:

some indexes rate-limit users based on credentials (e.g. have lower rate limits for unauthenticated users). Always providing credentials, instead of waiting for an error and retrying, seems to be a better behavior as it generates fewer network requests.

I don't feel able to judge if we should stick to it or not.

[codethief]

Just ran into this issue again: I did

mkdir new-project
cd my-project poetry init
poetry add <some dependency>

Unfortunately, this time I had forgotten to set PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring in my .envrc beforehand (as per #5250). As mentioned in the OP, this

[resulted] in uncountable popups requesting keyring access that one has to deny (hit cancel in my case) one after another

However, in my case, the prompt also prevented me (an i3 user) from switching to any other window or workspace. As a result, I had to switch to another TTY and killall poetry by hand because even after hitting ESC a hundred times, it didn't want to leave me alone. :\

I don't feel able to judge if we should stick to it or not.

In light of the above, I would vote for not sticking to this or at least making this behavior transparent to the user somehow before they invoke poetry add for the first time.

[tmplt]

This access attempt is prohibitive as I've just discovered poetry: I use GNOME, but not the keyring functionality, and on an interactive poetry init it asks me for a password. I thought it was asking me for my root password before I found this issue, prompting vendor security questions.

This is confusing and unexpected behavior.

[lersek]

This issue persists with version 1.8.3. As others stated above, the (seemingly) infinite loop of keyring password requests effectively locks up the GUI; it's not even possible to switch to a character VT. ssh from another machine is needed for a killall poetry.

It wouldn't be nearly as bad if we could at least specify a non-default collection on the keyring.

The PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring workaround works though, at least.