Bug#998105: chainer is still not supported (requires a cfg file as work-around)
See inline below ...
On Fri, 2023-02-24 at 16:26 +0100, Jürgen Altfeld wrote:
[...]
>
> I now realize (thanks to your persistence & asking the right
> questions - excellent soft skills BTW :-)
Thanks for the kudos :-)
[...]
>
> 1. Would you agree with my proposal to fix it (just enabling
> ChainerBackend in BiT)?
> Do you have other ideas/suggestions?
That's an excellent proposal. To me it seems the best solution.
> 2. Are you able (= still allowed) to apply a patch to the upcoming
> BiT package ("unstable" AFAIR) using my fix?
Bookworm is currently in Soft Freeze, so targeted fixes are still
possible. As I am only the reporter of the bug the maintainer, Jonathan
Wiltshire, needs to make sure the patch goes into BiT in time.
According to https://release.debian.org/testing/freeze_policy.html#hard
2023-03-12 is the deadline.
>
> THX a lot for your support!
>
My pleasure!
--
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585
signature.asc
Description: This is a digitally signed message part
Bug#998105: chainer is still not supported (requires a cfg file as work-around)
I have opened a new issue at BiT: https://github.com/bit-team/backintime/issues/1410 Would it be possible to continue or conversation about this bug there to make it visible for others (= non-Debian users of BiT)? THX :-)
Bug#998105: chainer is still not supported (requires a cfg file as work-around)
On Thu, 23 Feb 2023 21:38:55 +0100 Sven Geuer wrote:
> 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.
I fully agree with that!
> Would it be feasible to probe the supported backends for already stored
> BiT credentials and choose the matching backend automatically?
TLDR;
I propose that I open a new issue at BiT and fix this bug ASAP by enabling
ChainerBackend support in BiT.
I had already documented and prepared this
fix three months ago (but the code is still commented out):
https://github.com/bit-team/backintime/blob/e22c7f253fa048fab9119f4cbea34c0fa8d1aba6/common/tools.py#L889-L897
Details:
---
To give a little bit context to this issue with the "chainer" backend:
I (nickname "aryoda" at GH) have fixed some non-chainer-related keyring issues
in BiT and discovered
during my debug sessions the existence of the new "ChainerBackend" and its
impact.
Since we (the BiT developers) are currently only fixing bugs to stabilize
the new BiT release I did not want add support for another new and untested
password safe backend
so I have just documented a work-around and requested a new feature at the
keyring
homepage (https://github.com/jaraco/keyring/issues/602) together with a feature
request
for BiT ("add a GUI to choose a backend", see
https://github.com/bit-team/backintime/issues/1330).
I now realize (thanks to your persistence & asking the right questions -
excellent soft skills BTW :-)
I have totally under-estimated the impact of this keyring change:
The current and all old BiT versions do **NOT** support the ChainerBackend
(the supported backends are white-listed in BiT) which is now the default
in the new keyring package and I see a storm of new issues in front of us ;-)
So to come back to your question ("choose the matching backend automatically"):
This could possibly be implemented in BiT but
- it would be invisible to users again until we take this as default and
add the GUI to allow the user to change this
- an "old" password in an previously used password safe could "win the election"
- quite a similar logic is already implemented in the ChainerBackend in
`keyring` to get a password:
https://github.com/jaraco/keyring/blob/75b285d6f9d9b8cba33a9d5e9071cdd507b9/keyring/backends/chainer.py#L47-L51
So I propose that I open a new issue at BiT and fix this bug ASAP by enabling
ChainerBackend support in BiT.
Interestingly I had already documented and prepared this fix three months ago:
https://github.com/bit-team/backintime/blob/e22c7f253fa048fab9119f4cbea34c0fa8d1aba6/common/tools.py#L889-L897
BTW: I see one key difference between your proposal (to recognize the best
keyring backend in BiT)
and the ChainerBackend:
Password updates ("set_password"): ChainerBackend uses the first
(highest-rated) backend in the chain
while in BiT we could update an existing password in the same backend where the
old password exists
(may not be the same backend chosen by ChainerBackend!).
https://github.com/jaraco/keyring/blob/75b285d6f9d9b8cba33a9d5e9071cdd507b9/keyring/backends/chainer.py#L53-L58
Still implementing this advanced password update logic requires too much dev &
testing time now so I would rely
on the ChainerBackend for now and observe how users come back with issues (if
any) in the future...
So:
1. Would you agree with my proposal to fix it (just enabling ChainerBackend in
BiT)?
Do you have other ideas/suggestions?
2. Are you able (= still allowed) to apply a patch to the upcoming BiT package
("unstable" AFAIR) using my fix?
THX a lot for your support!
Bug#998105: chainer is still not supported (requires a cfg file as work-around)
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
> 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:
> > [, > '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
Bug#998105: chainer is still not supported (requires a cfg file as work-around)
On Tue, 21 Feb 2023 20:40:21 +0100 Sven Geuer 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)?
> 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:
> [, '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
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
