disable keyring per default

[radoering]

Pull Request Check List

Resolves: #8623
Resolves: #8761
Closes: #9820

Basically, #9820 without the extra part.

• Added tests for changed code.
• Updated documentation for changed code.

[abn]

I am wondering if we simply follow what pip's behavior is here.

https://pip.pypa.io/en/stable/topics/authentication/#keyring-support

The default value auto respects --no-input and does not query keyring at all if the option is used; otherwise it tries the import, subprocess, and disabled providers (in this order) and uses the first one that works.

The majority of the issues occur when keyring is used in a non-interactive session (ci/containers). To me, this is the best balance.

[radoering]

Do we auto-detect a non-interactive session? If users have to pass --no-interaction, I am afraid this will not help at all because users will still run into this issue.

[abn]

We do check. For example in https://github.com/python-poetry/poetry/blob/main/src%2Fpoetry%2Fconsole%2Fcommands%2Finit.py (sorry for the bad link on mobile).

[radoering]

The majority of the issues occur when keyring is used in a non-interactive session

Actually, I do not think that this is true. It seems like many users experience this issue when being on a headless system but there are also reports, which mention a GUI. Just some examples:

#8761 (comment)
#8761 (comment)
#8761 (comment)
#8623 (comment)
#8623 (comment)

[abn]

#8761 (comment)

The issue here really is when a scenario occurs where your login did not correctly unlock your system keyring. This is for example - first login using fingerprint, login password was changed without changing your keyring unlock credentials etc. This should really be solved in UX using a pre-flight check and detecting explicitly - a kerying exists and is locked - if interactive ask for password and passthrough.

This and many other of the linked comments also is the case for ssh access (eg: git via ssh) if your ssh key is locked.

#8623 (comment)
#8623 (comment)

Will be resolved if we detect headless.

#8761 (comment)
#8761 (comment)

Will potentially be resolved if we detect headless sessions and we ignore locked keyrings (or treat that as disabled). But I would definitely like to reproduce this somewhere as I have been unsuccessful in doing so till date.

To be clear I am not saying we don't want to do this, but I would like to at least make an informed choice here. Often times a lot of the comments around this are stale given that we have resolved issues through the releases. And keyring implementation is definitely better as well. And we cannot be held responsible for fixing broken distros.

@neersighted pinging you as well since you have had some insights on the topic as well?

PS: I am also locking this conversation to maintainers to avoid bike shedding.