disable keyring per default and only install via an extra

[radoering]

Pull Request Check List

Resolves: #8623
Resolves: #8761

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

disable keyring per default

I think the majority of Poetry users do not use/need keyring. Therefore, changing the default of keyring.enabled from true to false avoids issues like #8623 and #8761. In case, someone stores credentials with keyring disabled/unavailable, we have already warned that credentials will be stored in plain text. I extended this warning so it tells the user that they should consider using keyring.

keyring as an extra

Further, I moved keyring to an extra because it is responsible for one third of our dependencies on Linux (and still a quarter on Windows)! Without keyring, there are 13 dependencies less on Linux and 9 dependencies less on Windows.

Why care about the number of dependencies?

The installation of Poetry is about 1-2 seconds faster and about 18 MB smaller without keyring. Maybe not much, but especially installation speed might still be relevant (at least nice) in CI pipelines.

And the other side of the coin?

We have to make sure that Poetry still works (and keeps working) without keyring. There must not be an accidental use of keyring anywhere in the code!

I have taken a few measures that should ensure that no accidental use of keyring slips in in the future:

• disallow global keyring imports in src via TID253
• restrict keyring imports to one module (password_manager.py) via TID251
• extended test_password_manager.py::test_disabled_keyring_never_called to test_password_manager.py::test_disabled_or_unavailable_keyring_never_called

[github-actions]

Deploy preview for website ready!

✅ Preview
https://website-he51zpgfm-python-poetry.vercel.app

Built with commit 16a6c18.
This pull request is being automatically deployed with vercel-action

[abn]

@radoering I am a bit conflicted here. On the one hand I can understand the odd issues we have had regarding keyring. On the other hand however, I am also aware that one of the original reasons we implemented keyring as default was to encourage good credential hygiene by avoiding storing plaintext credentials into config files where possible. It is not a silver bullet, but a better security posture. The question I guess, is if security considerations are getting in the way of ux without much value gained.

The other rationales, like the dependency numbers and sizes etc, I do not think really applies here. And I reckon the config flag disabling keyring by default is likely a better solution.

And further majority of keyring issues I have seen has been due to the rather badly setup debian environments or containers.

[radoering]

I am a bit conflicted here.

I can fully understand. It took me a while to get to the point where I thought it is better to deactivate it per default.

The question I guess, is if security considerations are getting in the way of ux without much value gained.

I think we have reached this point because users run into keyring issues even when installing from sources without any authentication. Especially less experienced / new users are not able to identify and work around this issue quickly.

The other rationales, like the dependency numbers and sizes etc, I do not think really applies here.

Less dependencies -> less issues. 😉

I still like the extra but this is not a hill I want to die on.

@Secrus If I remember correctly, you are in the "reduce number of dependencies" team. Do you have a strong opinion on this one?