** Package changed: ubuntu => gnome-keyring (Ubuntu) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-keyring in Ubuntu. https://bugs.launchpad.net/bugs/569765
Title: Error storing/reveiving passwords into/from gnome-keyring Status in Screenlets — a framework for desktop widgets: Fix Released Status in Screenlets trunk series: Fix Released Status in “gnome-keyring” package in Ubuntu: New Bug description: Using any screenlet in Ubuntu Karmic which has password stored with AccountOption into gnome-keyring, the password won't be received after logout any more. Screenlets report "ERROR: Unable to read password from keyring:" and that's all. It is quite mainstram in TwitterScreenlet bugtracking http://code.google.com/p/twitterscreenlet/updates/list, for example. For me the problem was fixed at first when I just reversed the boolean operator fount in /usr/share/pyshared/screenlets/options.py inside function on_import, so instead of if self.keyring == self.keyring_list[0] i used if self.keyring != self.keyring_list[0]. This made the password to be received all right. The problem, however, seems to be that options.py makes a wild presumption about the order of keys in the ring. 237 self.keyring_list = gnomekeyring.list_keyring_names_sync() We have the keyrings' list now... But is there a default keyring defined? --- Yes? Then let self.keyring represent "the default keyring". --- No? Then let's take self.keyring represent "the whatever first keyring" that was available at the keyring... (that is 246 self.keyring = self.keyring_list[0]) Now, in my case "the whatever first keyring" is "login" which happens to be also "the default keyring", but I suppose "the whatever first keyring" could be also "session" or "foobar", but there's no way to be sure. If we now look, what is done in on_import 258 if self.keyring == self.keyring_list[0] and also on_export 278 if self.keyring == self.keyring_list[0] then it seems that it is meant to detect if we had some default keyring defined... But it fails. It supposes, that when we have default keyring defined the self.keyring != self.keyring_list[0], but it may well happen otherwise, as in my case and for lot of other people referref above. I suppose the order of keyrings is changing through versions of gnome-keyring application or Linux distribution, and once the code worked, but now it's broken. I suggest that since in on_export 279 auth_token = gnomekeyring.item_create_sync('session', 280 gnomekeyring.ITEM_GENERIC_SECRET, value[0], attribs, value[1], True) "the whatever first keyring" is replaced with the system keyring "session" as the hard-coded string, the value "session" should be as well assigned already in __init__ 246 self.keyring = self.keyring_list[0] instead of "the whatever first keyring", i. e. it should be 246 self.keyring = "session" The rest of hocus pocus with checking if there was default keyring or we are dealing some "random first keyring" should be removed and replaced with plain 262 pw = gnomekeyring.item_get_info_sync(self.keyring, 263 int(auth_token)).get_secret() in case of on_import and with 282 auth_token = gnomekeyring.item_create_sync(self.keyring, 283 gnomekeyring.ITEM_GENERIC_SECRET, value[0], attribs, value[1], True) in case of on_export... That should do it. If that's allright, I could check and fix the code myself. To manage notifications about this bug go to: https://bugs.launchpad.net/screenlets/+bug/569765/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
