Add password safe selection to settings GUI (internally setting the keyring backend)

[aryoda]

This is a feature request derived from the issues #1321 and #990.

Current situation

BiT allows to use a password safe to store passwords for local encryption and SSH (private key) via the Save Password to Keyring checkbox:

Problem description

Internally the keyring library is used to store and get the password(s).

keyring uses "drivers" (so called backends) to access password safes.

keyring does not know which of multiple installed password safes shall be used and uses a sensible default backend (currently the so called ChainingBackend which iterates over all installed backends and chooses one using internal priorities).

This has several drawbacks:

1. Not all of the keyring backends are working (supported by) BiT - there is a whitelist in the code. If keyring picks the wrong one the checkbox is disabled.

2. If new keyring versions or backends are installed eg. by other python-based apps keyring may pick another backend and can either no longer access a stored password or the backend not supported by BiT (see 1.)

3. To select a fixed backend the end user of BiT has to create a config file and know the (technical backend name (see https://github.com/bit-team/backintime#non-working-password-safe--bit-forgets-passwords-keyring-backend-issues).

   a) This configuration cannot be viewed and changed in the GUI (usability issue). b) If another application or user changes this per-user configuration file it also changes the backend the BiT uses.

4. If the "Save Password to Keyring" checkbox is grayed-out in the GUI the user has no chance to recognize the reason for this and what to change use a password safe.

5. The word "keyring" in the checkbox label "Save Password to Keyring" is difficult to understand because it is technical.

Expected behavior

1. The password safe (and the internally derived backend) setting must visible and changable in the GUI
2. Changing this setting shall not impact other apps
3. Changes of the per-user configuration file of the keyring backend shall have no impact on BiT unless the user willingly accepts this
4. If the "Save Password to Keyring" checkbox is grayed-out in the GUI (disabled) the user shall be able to recognize the reason for this and how to change it
5. Use a better name than "keyring" in the GUI
6. Non-functional: The BiT dependencies shall not be changed too much (eg. requiring a newer keyring library) to stay compatible with the currently supported OS landscape.

Proposed changes

1. Replace the term "keyring" in the "Save Password to Keyring" checkbox by eg. password safe ("keyring") to be more understandable.
2. Add a combo box to choose a password safe that BiT shall use for all profiles, eg. in the same row as the checkbox at the right side: Used password safe (for all profiles):
3. The combo box shall show all installed and supported (by BiT) password safes and the underlying technical keyring backend in parens (since multiple backends may support the same password safe via different protocols).
4. The combo box shall additionally contain the entry Use the keyring default backend which uses the default backend of keyring (which may be made the default via the keyring configuration file).
5. The combo box shall additionally contain the entries and (if no supported backend is installed)
6. Store the selected password safe (backend) in the profile configuration - not in the keyring per-user config file!

Open questions

• If the checkbox is grayed out: Does a user understand that a password safe must be selected in the combobox?
• If no supported backend is installed there is no password safe a user could choose from. How can a user recognize the required actions to enable (install) the backends and password safe?

Implementation hints

• Simply use the keyring.set_keyring() function

• Alternative: init_backend(limit=None) of keyring takes an optional limit (filter) argument which can take a callable "filter function" with the signature shall_the_backend_be_added_to_the_chain(backend): Bool. It sets the current backend to an instance of the marker backend fail.Keyring if no backend passed the filter which could be used by BiT to report "no supported keyring backend available".

  This requires keyring >= 17.1.

  https://github.com/jaraco/keyring/blob/bfa0148ab43ea9e592232c561971bf06712b625b/keyring/core.py#L101

• Decide if keyring.backends.chainer.ChainerBackend shall be added to the supported backends too.

  It is a meta backend that interates over all other installed backends. Since it seems to be the default in keyring it would always require to add a keyring config file manually (bad user experience ;-)

  On the other hand ChainerBackend does not guarantee that a BiT-supported backend is really found and used. So personally I'd prefer to either add a checkbox in the settings GUI to enable the Chainer or even better add add a backend selector into the settings GUI.

  See also this discussion with the keyring developer: https://github.com/bit-team/backintime/issues/990#issuecomment-1272014311

[aryoda]

@buhtz Just saw this FR (again) which could be a good candidate for a global settings dialog (together with the language selection)

[buhtz]

Yes. One more such a thing and we can open an "application settings FR" issue to collect them. ;)

[buhtz]

Might it be the case that a user do use multiple password safes on the same system? So that one snapshot profile use safe A and next snapshot profile use safe B? If this is a realistic use case that setting should be related the profile and not to the application itself. It would also be an approach to have an application global setting about the used password safe (keyring) and give the user the opportunity to overwrite that setting on the level of a snapshot profile.