Hi BiT Dev, thank you for the detailled reply.
More inline below ...
On Thu, 2023-02-23 at 01:53 +0100, BiT dev wrote:
> On Tue, 21 Feb 2023 20:40:21 +0100 Sven Geuer <debma...@g-e-u-e-r.de>
> wrote:
>
> > I still need to pin python3-keyring to use
> > keyring.backends.SecretService.
>
> What do you mean with "pin"? Installing an old version of python3-
> keyring (without the chainer) by pinning the ("old") DEB package
> (version)?
With "pin" I meant configuring python3-keyring per
~/.config/python_keyring/keyringrc.cfg:
[backend]
default-keyring=keyring.backends.SecretService.Keyring
More below ...
>
> > Unfortunately BiT version 1.3.3 still fails with a version of
> > python3-
> > keyring offering keyring.backends.chainer.
> > [...]
>
> TLDR:
> -----
>
> "chainer" is new and a "meta keyring" that decides internally which
> actually installed
> keyring will be used using some heuristics.
>
> "chainer" is not supported by BiT since the heuristics may choose
> another keyring in the future for any reason
> and the wrong keyring is used then (which does not contain the stored
> credentials for BiT).
>
> To solve (work around) this problem add a keyring config file to
> specify ("pin") which keyring you want
> to use instead of chainer, see these instructions here:
>
> https://github.com/bit-team/backintime#non-working-password-safe-and-bit-forgets-passwords-keyring-backend-issues
>
> -> Just use your prefered keyring in the config file:
>
> default-keyring=keyring.backends.SecretService.Keyring
>
>
>
> In full length:
> ---------------
>
> To really use a a keyring two things must be installed:
>
> 1. A supported keyring software (debian package)
> 2. A python library that has a "driver" to enable the keyring of 1.
> for python
>
> The BiT logs show that "secret service" is installed (satisfies above
> number 1.):
>
> > DEBUG: [common/tools.py:862 keyringSupported] Available keyring
> > backends:
> ...
> > DEBUG: [common/tools.py:865 keyringSupported]
> > keyring.backends.SecretService.Keyring (priority: 5)
>
> The BiT logs also show that above number 2. is satisfied
> ("python3-secretstorage" is installed together with "python3-keyring"
> AFAIR since it has a "depends" relationship):
>
> > DEBUG: [common/tools.py:899 keyringSupported] Available
> > supported backends:
> > [<class 'keyring.backends.SecretService.Keyring'>, <class
> > 'keyring.backends.kwallet.DBusKeyring'>]
>
> Since newer "python3-keyring" versions use "chainer" by default now
> (which is not supported by BiT) no keyring is available in BiT:
>
> > DEBUG: [common/tools.py:905 keyringSupported] No appropriate
> > keyring found. 'keyring.backends.chainer' can't be used with
> > BackInTime
>
>
I understand this all very well. The current situation just does not
deem user friendly to me. I am afraid the average user is unable to
detect what the problem is and how to fix it, especially as things
worked out of the box before python3-keyring 23.2.0-1 was introduced.
>
> Outlook:
> --------------
>
> I think I should add a link to above "known issues" section to the
> debug output.
>
> How the chainer issue could be fixed is described quite well in this
> feature request (add a GUI to select the keyring):
>
> https://github.com/bit-team/backintime/issues/1330
>
This may help, although it still requires sufficient insight on the
part of the user.
Would it be feasible to probe the supported backends for already stored
BiT credentials and choose the matching backend automatically?
Love to hear what you think.
Sven
--
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585
signature.asc
Description: This is a digitally signed message part
