"Save password to keyring" option is disabled

[Azimoth]

trafficstars

I'm having this issue using version 1.2.0~alpha0 on Gentoo. The thing is: It WAS working until I installed something else that required PyQt5.

Then backintime stopped working properly by complaining about being unable to access the password, so I removed it manually from kwallet, expecting to be asked for it again. Then the GUI didn't come up anymore, which I could fix by installing xdpyinfo.

Now Backintime is working again, but the "Save password to keyring" option is disabled.

I also tried re-installing Backintime (also removing ~/.config/backintime and ~/.local/share/backintime), but it still doesn't work.

backintime --debug

doesn't show anything that seems to be out of the ordinary...

I am well aware of #545, #587, #509 and #534 but the solutions presented there didn't work.+ python-secretstorage is installed,

$ python -c "import keyring; print(keyring.get_keyring())"
keyring.backends.chainer.ChainerBackend (priority: 10)

$ backintime pw-cache stop

Back In Time
Version: 1.2.0~alpha0

Back In Time comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type `backintime --license' for details.

WARNING: Failed to read PID and process name from /home/user/.local/share/backintime/password_cache/PID: [2] No such file or directory
ERROR: pidfile /home/user/.local/share/backintime/password_cache/PID does not exist. Daemon not running?

Since I added the password to my ssh-agent (via ksshaskpass) I don't have to enter it, when I open back in time manually. Only taking snapshots or changing settings require a password. (When cancelling without password, there's a message the password is "wrong or not available for cron".)

What am I missing here?

[joaoherberto]

I am having a similar issue, I am on an Arch based system, current BIT version is 1.1.12. I am wondering if the dependency of python3-keyring may be the issue. on an Arch system, the files are named python-keyring (it installs python3). Perhaps one of the devs could way in on this.

Does BIT look for python3 or just python paths?

[Azimoth]

I just noticed that

$ backintime backup

also works without manually entering a password. So the issue only exists using the qt gui...

[bentolor]

Same here on Ubuntu 18.10 / Gnome Shell. My error is:

 [common/tools.py:822 keyringSupported] No appropriate keyring found. 'keyring.backends.chainer' can't be used with BackInTime

Unfortuntely background backup does not seem to work for me. It looks like https://github.com/bit-team/backintime/blob/012d9783e966c6744ab30ce6abd299206a324473/common/tools.py#L796 is unable to find a supported keyring backend. I have gnome-keyring installed. Not sure if any binding library is missing?!

[bentolor]

Trying to dig deeper into the issue: My message seems to originate from https://github.com/jaraco/keyring – a Python lib to access key rings.

This also provides a CLI-Tool which i.e. can enumerate the backends:

$ keyring --list-backends 
keyring.backends.fail.Keyring (priority: 0)
keyring.backends.kwallet.DBusKeyring (priority: 4.9)
keyring.backends.kwallet.DBusKeyringKWallet4 (priority: 3.9)
keyring.backends.chainer.ChainerBackend (priority: 10)
keyring.backends.SecretService.Keyring (priority: 5)

Obviously keyring.backends.chainer.ChainerBackend gets chosen by priority but seems to be unknown to BIT. I also miss some Gnome-Shell Keyring: Only DBus?

[bentolor]

I seem have to fixed the issue. It looks like Jaraco has a bug and tries to access the wrong keyring. For example if i enter keyring get system username I receive a UI prompt to create a new Kwallet keystore. Don't wont to do that.

I have an upgraded Ubuntu 18.10 installation. Therefore I had to fix a few things. I'm not sure if the update steps below are required. Just tried them before:

1. I received some strange error on calling pip3. Deleted the outdated old binaries in /usr/local/bin: sudo rm /usr/local/bin/pip* and reinstalled via apt: sudo apt install --reinstall python3-pip
2. Updated SecretStorage pip3 install -U SecretStorage
3. Installed jeepney (unsure if needed): pip3 install jeepney
4. Following https://github.com/jaraco/keyring#id9:

$ python3 -c "import keyring.util.platform_; print(keyring.util.platform_.config_root())"
/home/ben/.local/share/python_keyring
$ mkdir -p /home/ben/.local/share/python_keyring
$ gedit /home/ben/.local/share/python_keyring/keyringrc.cfg

The content of /home/ben/.local/share/python_keyring/keyringrc.cfg:

[backend]
default-keyring=keyring.backends.SecretService.Keyring

Now keyring get system username directly returns with no result and I can re-check the "save password" in BIT.

[bentolor]

@Azimoth @joaoherberto With the explicit configuration in my comment above, I got everything working again. I also opened a ticket against jaraco/keyring because I'm unsure if the problem is inside BIT or that library.

[Azimoth]

@bentolor Awesome! It works! How the hell did you figure that out?

Thanks a lot!

[joaoherberto]

@bentolor I had to create the python_keyring directory and the cfg file and it worked. On my system, fresh install of Cinnamon Desktop on Manjaro, creating the keyringrc.cfg file and adding the [backend] comment is all it took.

Much appreciated!

[powerriegel]

I have the issue on Kubuntu 19.04 running BIT 1.1.24. Found a lot of closed issues here but it still seems to be unsolved.

backintime-qt4 --debug prints DEBUG: [common/tools.py:618 keyring_supported] No appropriate keyring found. 'keyring.backends.chainer' can't be used with BackInTime

And $ python -c "import keyring; print keyring.get_keyring()" keyring.backends.chainer.ChainerBackend (priority: 10)

The SSH volume can be mounted, I can see all the older backups but when BIT starts a new backup, then it asks every time for a passphrase. I can't tick the "Save password in keyring" option.

python3-secretstorage and python3-keyring are installed.

When I run backintime backup in terminal everything works fine?! But if I do nothing (except surfing) and BIT is set to daily backup, then the SSH passpjhrase dialog pops over every day.

[bentolor]

@powerriegel I see this as a confirmed, unfixed issues with latest Jacoco shipped with newer Ubuntus.

To workaround:

$ python3 -c "import keyring.util.platform_; print(keyring.util.platform_.config_root())"
/home/ben/.local/share/python_keyring
$ mkdir -p /home/ben/.local/share/python_keyring
$ gedit /home/ben/.local/share/python_keyring/keyringrc.cfg

The content of /home/ben/.local/share/python_keyring/keyringrc.cfg:

[backend]
default-keyring=keyring.backends.SecretService.Keyring

[powerriegel]

powerriegel@host:~/.local/share$ python3 -c "import keyring.util.platform_; print(keyring.util.platform_.config_root())" 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 175, in activate_name_owner
    return self.get_name_owner(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 361, in get_name_owner
    's', (bus_name,), **keywords)
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'org.freedesktop.secrets': no such name

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/secretstorage/util.py", line 55, in bus_get_object
    return bus.get_object(name, object_path, introspect=False)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 241, in get_object
    follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 248, in __init__
    self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 180, in activate_name_owner
    self.start_service_by_name(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 278, in start_service_by_name
    'su', (bus_name, flags)))
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/keyring/backends/SecretService.py", line 35, in priority
    list(secretstorage.get_all_collections(bus))
  File "/usr/lib/python3/dist-packages/secretstorage/collection.py", line 144, in get_all_collections
    service_obj = bus_get_object(bus, SS_PATH)
  File "/usr/lib/python3/dist-packages/secretstorage/util.py", line 59, in bus_get_object
    raise SecretServiceNotAvailableException(e.get_dbus_message())
secretstorage.exceptions.SecretServiceNotAvailableException: The name org.freedesktop.secrets was not provided by any .service files

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/keyring/__init__.py", line 3, in <module>
    from .core import (
  File "/usr/lib/python3/dist-packages/keyring/core.py", line 189, in <module>
    init_backend()
  File "/usr/lib/python3/dist-packages/keyring/core.py", line 97, in init_backend
    or load_config()
  File "/usr/lib/python3/dist-packages/keyring/core.py", line 176, in load_config
    return load_keyring(keyring_name)
  File "/usr/lib/python3/dist-packages/keyring/core.py", line 137, in load_keyring
    class_.priority
  File "/usr/lib/python3/dist-packages/keyring/util/properties.py", line 26, in __get__
    return self.fget.__get__(None, owner)()
  File "/usr/lib/python3/dist-packages/keyring/backends/SecretService.py", line 38, in priority
    "Unable to initialize SecretService: %s" % e)
RuntimeError: Unable to initialize SecretService: The name org.freedesktop.secrets was not provided by any .service files

:-(

[bentolor]

@powerriegel This sounds like you are trying to access the Gnome Keyring but don't have any Gnome Keyring installed. See also https://ahelpme.com/linux/dbusexception-could-not-get-owner-of-name-org-freedesktop-secrets-no-such-name/

If you have KDE installed and want to use KWallet, you need to change the content of keyringrc.cfg so that it tries to access the KDE secret store instead.

Probably it should be

[backend]
default-keyring=keyring.backends.kwallet.DBusKeyring

OR

[backend]
default-keyring=keyring.backends.kwallet.DBusKeyringKWallet4

[powerriegel]

Hell, yes! The first one worked!

[mspacek]

secretstorage.exceptions.SecretServiceNotAvailableException: The name org.freedesktop.secrets was not provided by any .service files

@powerriegel I got the same error message while simply trying to run pip3 (but not pip2) and getting frustrated with it taking so long for no apparent reason, and hitting Ctrl+C.

The tip from @bentolor fixed it for me:

2. Updated SecretStorage pip3 install -U SecretStorage

Now pip3 runs instantly.

Here was the output:

Collecting SecretStorage
  Downloading https://files.pythonhosted.org/packages/82/59/cb226752e20d83598d7fdcabd7819570b0329a61db07cfbdd21b2ef546e3/SecretStorage-3.1.1-py3-none-any.whl
Requirement already satisfied, skipping upgrade: cryptography in /usr/lib/python3/dist-packages (from SecretStorage) (2.1.4)
Collecting jeepney
  Downloading https://files.pythonhosted.org/packages/0a/4c/ef880713a6c6d628869596703167eab2edf8e0ec2d870d1089dcb0901b81/jeepney-0.4.1-py3-none-any.whl (60kB)
     |████████████████████████████████| 61kB 6.2MB/s 
Installing collected packages: jeepney, SecretStorage
  Found existing installation: SecretStorage 2.3.1
    Uninstalling SecretStorage-2.3.1:
      Successfully uninstalled SecretStorage-2.3.1
Successfully installed SecretStorage-3.1.1 jeepney-0.4.1

I guess some buggy version or failed previous install of SecretStorage was the source of the problem.

[rapgro]

Duplication of #545, #509 and others (already closed)?

[bentolor]

@rapgro I think no – this is a new issue.

Please check the discussion here and especially https://github.com/jaraco/keyring/issues/391 for the according upstream bug report.

[rapgro]

Thanks for the hint. We've to take care in Fedora as downstream. https://bugzilla.redhat.com/show_bug.cgi?id=1789073

[bentolor]

FYI: The author of the keyring library @jaraco discussed in this comment, how back-in-time should probably handle the keystore: https://github.com/jaraco/keyring/issues/391#issuecomment-625361282

I do not understand the details so I cannot say if this would solve the issue, but the proposed change looks rather minimalistic.

[pclinuxer]

Hello:

As explained in this post https://dev1galaxy.org/viewtopic.php?id=4186, I came across this BIT/keyring when hunting down error messages in my syslog, albeit with BIT (apparently) working correctly.

@bentolor -> thanks a lot for finding and posting the fix.

Has it been addressed in the last version (1.3.0) of BIT?

Thanks in advance,

PCL

[kirmonkey]

/home/$user/.local/share/python_keyring/keyringrc.cfg

[backend] default-keyring=keyring.backends.kwallet.DBusKeyring

I can confirm that the above, as commented by bentolor on the 14th August 2020, works on Debian 10 with KDE desktop. BIT 1.1.24

Peace and backups.

[JamesClarke7283]

I seem have to fixed the issue. It looks like Jaraco has a bug and tries to access the wrong keyring. For example if i enter keyring get system username I receive a UI prompt to create a new Kwallet keystore. Don't wont to do that.

I have an upgraded Ubuntu 18.10 installation. Therefore I had to fix a few things. I'm not sure if the update steps below are required. Just tried them before:

1. I received some strange error on calling `pip3`. Deleted the outdated old binaries in `/usr/local/bin`: `sudo rm /usr/local/bin/pip*` and reinstalled via apt: `sudo apt install --reinstall python3-pip`

2. Updated SecretStorage `pip3 install -U SecretStorage`

3. Installed jeepney (unsure if needed): `pip3 install jeepney`

4. Following https://github.com/jaraco/keyring#id9:

$ python3 -c "import keyring.util.platform_; print(keyring.util.platform_.config_root())"
/home/ben/.local/share/python_keyring
$ mkdir -p /home/ben/.local/share/python_keyring
$ gedit /home/ben/.local/share/python_keyring/keyringrc.cfg

The content of /home/ben/.local/share/python_keyring/keyringrc.cfg:

[backend]
default-keyring=keyring.backends.SecretService.Keyring

Now keyring get system username directly returns with no result and I can re-check the "save password" in BIT.

Your solution worked for me, The "Save Password to Keyring" box. is no longer greyed out. It remembered, even after running: backintime pw-cache stop

I am running, Trisquel Nabia(Ubuntu Focal) backintime 1.3.2 backintime-qt 1.3.2 Using Gnome keyring.

I first used @mspacek suggestion and it was updated, now this is the version: I don't know if that also contributed to the fix, because the python3-secretstorage package is version 2.3.1-2

james@PC-13878:~$ pip3 install -U SecretStorage
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: SecretStorage in ./.local/lib/python3.10/site-packages (3.3.2)
Requirement already satisfied: cryptography>=2.0 in /usr/lib/python3/dist-packages (from SecretStorage) (2.8)
Requirement already satisfied: jeepney>=0.6 in ./.local/lib/python3.10/site-packages (from SecretStorage) (0.8.0)

[buhtz]

@Azimoth There is a new forming maintaining team and we do review all issues. Is this problem still relevant for you, can you reproduce it with a newer or the latest release? Did you find a solution?

Tag: Bug, Feedback, External

Keyring is the topic here. Not my expertise.

[emtiu]

Maybe someone who has looked into this more deeply could say if this looks like a duplicate of #1321 or not. //cc @aryoda @petaramesh

[petaramesh]

These issues seem related, the important thing being the need of :

~/.config/python_keyring/keyringrc.cfg containing : [backend] default-keyring=keyring.backends.kwallet.DBusKeyring

...Which seems necessary to “steer” the keyring system to using the correct backend.

However I wouldn't say these are duplicates, as #1321 is about the “save password” box being greyed out when opening the config dialog the 1st time, but being available after closing and reopening it.

I'm also under the impression that there might be side-effects when the SSH key password is both stored in the ssh-agent and available from the KDE Wallet (or other keyring mechanism).

[aryoda]

However I wouldn't say these are duplicates, as https://github.com/bit-team/backintime/issues/1321 is about the “save password” box being greyed out

No duplicate since the observed behavior is different (even though the reason may be the same but that is hard to say without more diagnostic output and looking into the different code versions).

I am preparing a PR to extend the diagnostic and debug output to make it easier for us to examine keyring issues in the future...

Edit: Extended diagnostics is now implemented with fix for #1321: 'backintime --diagnosticsandbackintime-qt --debug` to show more keyring debug output...

[Kajot-dev]

So essentialy if you have multiple secret stores (and thus multiple backends available) installed or just have the kwallet >= 5.97, (beacuse it supports secretservice+libsecret as well - see https://invent.kde.org/frameworks/kwallet/-/merge_requests/11) the box will be grayed out for you unless you configure the default keyring as either keyring.backends.SecretService.Keyring or keyring.backends.kwallet.DBusKeyring. This is because keyring.backends.chainer backends starts to have the highest priority - it iterates over the rest of the available backends. The problem is backintime considering it as "not appropriate". So in my opinion, backintime should use keyring.backend.get_all_keyring() and check for:

• keyring.backends.kwallet.DBusKeyring
• keyring.backends.SecretService.Keyring
• keyring.backends.libsecret.Keyring

And if any of the mentioned above is present, should consider keyring.backends.chainer keyring "appropriate"

[aryoda]

@Kajot-dev THX for your proposal, I came to a similar result documented in this issue (and am just preparing a simple fix for now):

https://github.com/bit-team/backintime/issues/1321#issuecomment-1271689827

The chainer has one issue: If none of the underlying backends is supported by BiT this may cause other errors in BiT because BiT thinks the keyring is available but it isn't.

[jaraco]

And if any of the mentioned above is present, should consider keyring.backends.chainer keyring "appropriate"

The intention of keyring is that the default behavior should be suitable. If the presence of the chainer is causing problems, it probably shouldn't be enabled by default or at the very least should have an escape hatch (a way for a library like backintime to disable its usage). I'd be happy to support such a thing in keyring if simply honoring chainer as "appropriate" isn't suitable.

~/.config/python_keyring/keyringrc.cfg containing ... necessary to “steer” the keyring system to using the correct backend.

That's annoying. Ideally, there would be a better mechanism to steer keyring to the desired behavior short of writing a user-global settings file. If honoring an environment variable or some other mechanism would help, keyring would be interested in exploring making this use-case simpler.

[aryoda]

The intention of keyring is that the default behavior should be suitable. If the presence of the chainer is causing problems, it probably shouldn't be enabled by default or at the very least should have an escape hatch (a way for a library like backintime to disable its usage). I'd be happy to support such a thing in keyring if simply honoring chainer as "appropriate" isn't suitable.

chainer is a cool thing and my challenge is now that the keyring API and configuration should more or less be hidden to end users since it is meant for developers or customizers (it should be a black box to end users IMHO).

So I have to give the end-user of Back In Time a simply way to configure this from the Back-in-Time-app point of view (user should not need to learn internals of keyring).

keyring's chainer uses some "heuristics" that seems to work non-deterministically from the Application point-of-view since external installations or settings may influence the priority value (I still have not completely browsed the keyring code so this is still more opinion than fact based I admit).

So the end user just want's to specify and persist the used "password safe" instead of a technical backend of an App-internal library.

And until the user does specify a "password safe" the "best guess" is the chainer so the default is good IMHO.

What would be nice in keyring to improve embedding it into an CLI or GUI app:

1. Add a public method to query for supported "password safes" (internally asking all available backends) return a list of the "pretty-labeled" password safes and a list of responsible backend names for each password safe to be used internally by 2.

   This would allow to fill a GUI widget more easily.

   Open question: How to cope with the 1:n nature of password safe to backends in the GUI then. The end user must take a decision for a backend finally, but based on which information?

2. Add a public method to persist the chosen backend without editing a file. An app (as keyring client) shoudn't have to know the storage location and file format (= encapsulate this in keyring). Optionally this setting could be valid only for a app (could be passed as key) but I assume that the selection should be right for every app/client then.

3. I assume we don't need to add an API to read the config file since the active backend (dominated by an existing config file) can already be queried with get_keyring().

~/.config/python_keyring/keyringrc.cfg containing ... necessary to “steer” the keyring system to using the correct backend. If honoring an environment variable or some other mechanism would help, keyring would be interested in exploring making this use-case simpler.

I think a persistence API would be more helpful than another env var (see proposal 2).

[aryoda]

I vote to close this issue because the solutions are:

No appropriate keyring found. 'keyring.backends.chainer' can't be used with BackInTime

1. The chainer backend is not supported by BiT at the moment and the solution is to add a keyring configuration file like described above or in our README now (may additionally require to install a password safe)

The "Save password to keyring" option is disabled in the settings GUI

2. This can either be solved

   • by configuring a supported keyring (as described in 1. - use the backintime-qt --debug to start the GUI and check if the "'keyring.backends.chainer' can't be used with BackInTime" message is shown.
   • using the most-recent BiT version that contains the fix of #1321

3. Extending the settings GUI to choose a supported and installed keyring backend is subject of a new FR #1330

Any objections?