On Thu, 23 Feb 2023 21:38:55 +0100 Sven Geuer <debma...@g-e-u-e-r.de> 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/7ffff5b285d6f9d9b8cba33a9d5e9071cdd507b9/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/7ffff5b285d6f9d9b8cba33a9d5e9071cdd507b9/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!
