A less hacky workaround for apparent bug in gnome-keyringmanager when password is an empty string. Trap the error, which is unfortunately somewhat generic due to the way dbus-python calls it, from gnome-keyringmanager and return an empty password.
After spending more time on this, the issue appears to be inside the gnome-keyringmanager when called via dbus-python. Unfortunately, the way dbus-python calls the dbus functions we cannot get more detailed error messages i.e. this is from conn-methods..c
/ FIXME: if we instead used send_with_reply and blocked on the resulting
* PendingCall, then we could get all args from the error, not just
* the first /
This workaround catches the exception thrown for this case and returns an empty password. It appears to be a unique scenario but there is always the possibility that another raises the same error.
Jason and I briefly discussed using a specific token to replace an empty password, but that approach means that anyone who copies the password directly from the Gnome keyring UI for pasting into an app will be copying an incorrect value.
This approach is an improvement, although still less than ideal, but should suffice until the underlying issue is resolved.
Ah, yes... this is a followup to a problem that I discovered when looking at issue #91. I had started a branch to address it and pinged Jason about it. He pointed out that branching is not the preferred mercurial approach, but a pull request is. So I spent some more time looking at it and came up with an alternative in this pull request.
The problem we see is that the SecretService tests are failing when the pasword is set to an empty string in check_set_get() from test_backend.py. This has been sneaking past because the SecretService keyring is only enabled when the dbus module is present AND a gui is present see (is_dbus_supported() from test_SecretService.py) which isn't the case in the standard test environments e.g. travis.
As detailed in the original comment above, this appears to be a gnome_keyringmanager/dbus-python interaction problem that we cannot directly rectify. This pull request has an alternative workaround to that in my original branch that doesn't require messing with the stored password which has several potential problems.